System and method to publish information from servers to remote monitor devices

ABSTRACT

To assist in monitoring the intelligent messaging network, a system and method for publishing logging and status information from the servers is provided. A list of available servers accessible for monitoring by persons, devices, and applications via a remote monitor device can be provided. The remote monitor device may forward selected servers from the list of available servers in which they are interested. Also, particular information about the selected servers can be requested. Access to certain servers and information may be restricted to those with authorization. Authorization can be verified by the use of digital certificates. The requested information can then be gathered and provided to authorized persons or devices. Typically, the information includes logging and status information from the servers. The information can be provided as an XML page and viewed using, for example, a standard web browser. Further, if the information is provided to the remote monitor device as an XML page, a standard XML parser may be used to extract particular information from the XML page.

CROSS-REFERENCE TO RELATED PATENT APPLICATION

The present invention is a continuation of U.S. patent application Ser.No. 13/067,778, entitled “A System and Method to Publish Informationfrom Servers to Remote Monitor Devices,” to Clubb et al., filed on Jun.27, 2011; which in turn is a continuation of U.S. patent applicationSer. No. 12/656,861, entitled “A System and Method to PublishInformation from Servers to Remote Monitor Devices,” to Clubb et al.,filed on Feb. 18, 2010, now U.S. Pat. No. 7,970,898; which in turn is acontinuation of U.S. patent application Ser. No. 12/219,495, entitled “ASystem and Method to Publish Information from Servers to Remote MonitorDevices,” to Clubb et al., filed on Jul. 23, 2008, now U.S. Pat. No.7,693,981; which in turn is a continuation of U.S. patent applicationSer. No. 11/366,009, entitled “A System and Method to PublishInformation from Servers to Remote Monitor Devices,” to Clubb et al.,filed on Mar. 2, 2006, now U.S. Pat. No. 7,418,498, which in turn is acontinuation of U.S. patent application Ser. No. 09/767,951, entitled “ASystem and Method to Publish Information from Servers to Remote MonitorDevices,” to Clubb, et al., filed on Jan. 24, 2001, now U.S. Pat. No.7,024,474, which is a continuation-in-part of U.S. patent applicationSer. No. 09/494,553, entitled “A Messaging Method and Apparatus ForSending and Receiving Messages In A Client Server Environment OverMultiple Wireless Networks,” to Zombek, et al., filed on Jan. 31, 2000,now abandoned, the contents of which are incorporated herein byreference in their entireties.

The present invention is related to U.S. patent application Ser. No.09/694,297, entitled “A Messaging Method and Apparatus For Sending andReceiving Messages In A Client Server Environment Over Multiple WirelessNetworks,” to Zombek, et al., filed Oct. 24, 2000, of common assignee tothe present invention, the contents of which is incorporated herein byreference in its entirety.

FIELD OF THE INVENTION

The present invention relates in general to the field of communicationsand more particularly to messaging between client devices and serversover multiple wireless networks that use different access protocols.

BACKGROUND OF THE INVENTION

Recent advances in hardware and communication technologies have broughtabout an era of client computing over wired and wireless networks. Theproliferation of powerful notebook computers and wireless client devicespromises to provide client end users with network access at any time andin any location over various networks, including the Internet. Thiscontinuous connectivity allows users to be quickly notified of changingevents, and provides them with the resources necessary to respond inrealtime even when in transit. For example, in the financial servicesindustry, online traders and financial professionals may be given thepower to access information in real-time, using wireless client devices.

Conventionally, however, developers of complex, wireless messagingsolutions have been forced to develop applications that are specific tovarious device types and network access protocols in diverse enterprisearchitectures and platforms. In other words, conventional clientcomputing solutions have been largely platform-specific,network-specific, or both. For example, messages may be generated by awide variety of applications running on a wide variety of clientdevices, such as Palm computing platform devices, Windows CE devices,paging and messaging devices, laptop computers, data-capable smartphones, etc. Depending on the type of network used by service providers,the client-generated messages may be transported over networks havingvarious access protocols, such as, e.g., Cellular Digital Packet Data(CDPD), Mobitex, dial-up Internet connections, Code Division MultipleAccess (CDMA), Global System for Mobile Communications (GSM), andReFlex. As a result, current developers of client computing solutionsmust have intimate knowledge of specific network characteristicsincluding, e.g., wireless network characteristics, protocolenvironments, and wireless links channel characteristics. Therefore,there exists a need to simplify wireless client and server applicationdevelopment environments to support the wide variety of device andnetwork dependent architectures.

Messaging Application Programming Interface (MAPI) is a messagingarchitecture and an interface component for applications such aselectronic mail, scheduling, calendaring and document management. As amessaging architecture, MAPI provides a consistent interface formultiple application programs to interact with multiple messagingsystems across a variety of hardware platforms. MAPI provides crossplatform support through such industry standards as Simple Mail TransferProtocol (SMTP), X.400 and common messaging calls. MAPI is also themessaging component of Windows Open Services Architecture (WOSA).

Accordingly, MAPI is built into such operating systems as, e.g., Windows95, Windows 98, Windows NT and Windows 2000, available from MicrosoftCorporation of Redmond, Wash., U.S.A. and can be used by 16-bit and32-bit Windows applications. For example, a word processor can senddocuments and a workgroup application can share and store differenttypes of data using MAPI. MAPI separates the programming interfaces usedby the client applications and the service providers. Every componentworks with a common, Microsoft Windows-based user interface. Forexample, a single messaging client application can be used to receivemessages from fax, a bulletin board system, a host-based messagingsystem and a LAN-based system. Messages from all of these systems can bedelivered to a single “universal inbox.”

Transmission Control Protocol (TCP) is a transport layer protocol usedby an application in one host to communicate with an application inanother host. This is accomplished by services provided by the protocollayers beneath the transport layer in both hosts. As aconnection-oriented protocol TCP requires the establishment of aconnection between the two hosts before two applications are able tocommunicate. TCP manages the connection and once both applications havecommunicated all required information between themselves the connectionis released as if the connection is two simplex connections as opposedto a single duplex connection. The information is transferred betweenapplications on different hosts is a byte stream. The transport layerhides message transfer details such as segmentation, ordering andduplication from the applications and provides end-to-endacknowledgement.

The Internet Protocol (IP) layer provides certain services to thetransport layer protocol including hiding the details of the physicaland data link layers and the services provided by them from thetransport layer protocol. The IP layer provides a datagram deliveryservice. A datagram is a unit of data less than an entire message. Amessage may be, for example, a file, which may be quite large. Sincethere is a maximum size for a message (or file), the message may have tobe segmented and transferred in smaller units. These smaller units arethus called datagrams. Each datagram is sent over the network as aseparate entity and may, in fact, follow separate paths to thedestination host. At the destination host, the datagrams are reassembledin proper order (usually in a buffer area) by the transport layer. Eachnode on the network sends any datagrams on to a next node onlyconsidering the final destination and only acknowledges receipt of thedatagram to the preceding node. That is, the IP layer does not provideend-to-end acknowledgement. End-to-end acknowledgement is a service ofthe transport layer protocol. Should the preceding node not receive anynode-to-node acknowledgements, the datagram or datagrams unacknowledgedwill be retransmitted. The transport layer in the destination host willalso acknowledge any duplicated datagrams (else receipt of duplicatedatagrams will continue resulting in a clogged network) and ignore them.

Routing between network nodes is accomplished by means of routingtables. These routing tables can be static or dynamic and result indatagrams being forwarded from a source host to a destination host onenode at a time. The intermediate nodes are often called “hops.”

The acronym, TCP/IP, is also used to refer to a five layer protocolmodel similar to the ISO/OSI seven layer protocol model. The TCP/IPmodel does not have the equivalent to layers 5 and 6 of the ISO/OSIprotocol model. A protocol model defines the protocol layers and theinterfaces between the layers. When implemented in software, hardware orfirmware or possibly field programmable gate arrays (FPGAs), theimplementation provides the actual services. This layered approachallows for ease of upgrading so long as the interface to the layerimmediately above or below is not altered. Layering also allows forcomplete substitution. For example, should a new physical medium becomeavailable then so long as the interface between layer two and layer oneremain the same, an old physical layer implementation module can beremoved and a new implementation module substituted. In the alternative,the new implementation module could be added as another option. That is,the protocol suite defines the rules and the implementation provides theservices that allow the communications to take place betweenapplications on different hosts. The implementation of the TCP layerprovides for the application to require a certain Quality of Service(QOS) as specified by a set of parameters including but not limited topriority, transmission delay, throughput etc.

Another well-known transport layer protocol is known as User DatagramProtocol (UDP), which is a connectionless transport protocol. The basicdata transfer unit is the datagram. A datagram is divided into headerand data areas as it is for the IP layer. An additional header over andabove the IP header is used. The UDP header contains source anddestination addresses (ports), a UDP length field (the length includesthe 8 byte header and the data) and a UDP checksum. The UDP dataincludes the IP header and data. The IP layer supports UDP as aconnectionless transport protocol for use in transmitting, for example,one time request-reply type messages or applications where time is ofgreater importance than accuracy.

TCP is used by applications on different hosts to communicate over anassumed unreliable network. To accomplish such communication much isadded to the protocol in order to ensure that the informationtransferred over the network is valid. This addition has a cost and thatcost is increased overhead with the attendant increase in bandwidth. AUDP header is eight bytes, the TCP header is 24 bytes and an IP headeris a minimum of 20 bytes. Therefore, UDP/IP headers are a minimum of 28bytes and TCP/IP headers are a minimum of 44 bytes. This is fairly largein terms of overhead and bandwidth utilization particularly overwireless networks. There are other significant problems with usingstandard TCP/IP over wireless networks principally in the area of flowcontrol. The UDP/IP protocol combination, while not offering anyguarantees to users, is expected to be reliable. Wireless networks tend,however, by their nature to be lossy. Several solutions have beenproposed when the network is not homogeneous. That is, when the networkhas both wireless and wireline portions. One suggestion is to useindirect TCP and another is to use snooping.

Other protocols such as Serial Line IP (SLIP) and Point to PointProtocol (PPP) have been developed. SLIP is not a standard and both arefor point to point connections only so are not available for uses innetworks. CDPD vendors indicate that they provide an integrated TCP/IPstack but it is not known the cost in terms of bandwidth overhead.

Conventionally, the existing wireless protocols do not provide anend-to-end solution over multiple networks and multiple client devices.Therefore, in addition to the need for a common architecture through asingle, user friendly methodology for providing effective and reliablewireless data solutions for hand-held and laptop computing devices,wireless networks; and legacy systems, there also exists a need toefficiently and reliably communicate data using minimum bandwidth.

SUMMARY OF THE INVENTION

The present invention features a system, method and computer programproduct that in an exemplary embodiment is operative to provide amulti-network transport programming interface that can enableclient/server applications to be written easily, where such applicationscan allow client applications running on client devices to communicatemessages with server applications across one or more wireless andwire-line networks. Moreover, the present invention in an exemplaryembodiment offers features for communicating such messages over wirelessnetworks efficiently, without requiring significant bandwidth, avaluable resource in wireless networks. In a further embodiment, theinvention provides for transmitting unsolicited messages from servers toconnectionless client devices.

Briefly, the present invention in an exemplary embodiment includes asystem for communicating messages in a client-server environment overone or more wireless networks that can support different networkprotocols. In an exemplary embodiment, the system of the inventionincludes a client device operative to execute a client application, anda back-end server (BES) operative to execute a server application. In anexemplary embodiment, a protocol gateway (PG) can encapsulate anunderlying network protocol of the plurality of wireless networks. In anexemplary embodiment, a client application and the server applicationcan communicate messages with each other through the PG independently ofthe underlying network protocol of the wireless network used for suchcommunication.

Conventional session-based transport protocols (e.g. TCP) are designedfor LAN-based systems with little network latency. These session-basedtransport protocol implementations are extremely chatty and were notdesigned to consider the amount of bytes sent over the network tomaintain the state of a connection.

Advantageously, the present invention, in an exemplary embodiment,features a highly optimized semi-reliable data transport protocol,simple network transport layer (SNTL). The transport protocolimplementation, in an exemplary embodiment, can optimize the over theair communication by using a connectionless send and receive mechanism.In addition, or alternatively, in an exemplary embodiment, the presentinvention can provide multiple compression mechanisms to reduce theamount of information that needs to be sent over the air. In anexemplary embodiment, in order to provide a reliable mechanism over aconnectionless environment, the transport protocol implementation canprovide for message segmentation and reassembly, message retries, ormessage ACK and NACK service for each supported wireless network. In anexemplary embodiment, message segments that are not acknowledged by thepeer protocol layer within the configurable time frame can be retriedautomatically by the transport protocol implementation. In order tofacilitate the request and provision of services, the interfaces betweenlayers can be clearly defined for peer-to-peer communication betweencorresponding layers of both sides of a connection. That is, theprotocol stack on each side (client and server) can be symmetrical. Thiscan allow two machines to specify how they communicate with one anotheron a level-to-level basis, rather than having to negotiate one giantprotocol for the entire network. This means that logical communicationscan occur at the peer protocol layer. On the client side for wirelesscommunications this can be called a peer wireless protocol layer. In anexemplary embodiment, the client or server applications do not need tobe concerned with segmenting the message and performing message retries.In addition to performing message retries, the transport protocolimplementation can support message duplication detection. In anexemplary embodiment, to support this reliable mechanism over aconnectionless environment, the transport protocol implementation canadd only four to six bytes to each application message. In an exemplaryembodiment, SNTL can include a novel and non-obvious hybrid protocolincluding many of the advantages of TCP but connectionless as is UDP.Further, in an exemplary embodiment, there can be less overhead than isrequired by conventional TCP.

The present invention, in an exemplary embodiment, can also use awireless connectivity middle layer gateway, which can be developed usinga wireless software development environment. The environment caninsulate a developer from the complexities of the underlying detailsrelated to devices and protocols.

In an exemplary embodiment, the environment can be packaged,advantageously, as a software development toolkit (SDK). The developercan work at the application layer by using the SDK. The SDK, in anexemplary embodiment, can include, e.g., software libraries for clientand/or server application development. The present invention, in anexemplary embodiment, can support solutions and software engineeringusing technologies such as, e.g., Windows NT/95/98/2000, Open DatabaseConnection (ODBC) compliant databases, Palm OS, and Windows CE clientdevices, and CDPD, Mobitex and dial-up networks.

Advantageously, wireless technologies and client devices can remaintransparent to the data source through the use of client and serverapplication programming interfaces (APIs) that can support multipleoperating environments including, for example, Palm OS, RIM, Windows 95,98, 2000, CE and NT, UNIX, Linux, and other variations of UNIX, etc.These well-defined APIs can use a set of portable class libraries to aidin rapid application development. Access to the intelligent messagingnetwork of the present invention can be via wireless client devices orvia a dial-up or leased line or other wireline connection coupled via,e.g., an Internet service provider (ISP), a network service, provider(NSP), a private network, or a virtual private network (VPN). That is,enterprise support, can be provided for and to, wireless clients andclients that need to access the intelligent messaging network of thepresent invention via a wired connection or dial-up line. This lattergroup of clients can be called Internet proxy clients, i.e., clientsthat can use a proxy server for access to the Internet. As clientdevices and wireless network technologies evolve, this system can ensurethat data solutions are supported.

In an exemplary embodiment, the messaging system communicates a messagebetween a client device and servers over a plurality of wirelessnetworks, each of which is adapted to support one or more wirelessnetwork protocols. A web server communicates with the servers. The webserver can send information about the servers to remote monitor clients.The monitoring can be performed by publishing a list of availableservers to the remote monitor clients. A selection of servers isreceived from the remote monitor clients. Information about the selectedservers is dynamically generated with the web server. The dynamicallygenerated information is provided from the web server to the remotemonitor clients.

In a further embodiment, a monitoring process includes receiving a listof available servers at the remote monitor client from the web server. Aselection of servers is made from the list of available servers. A listof selected servers is transmitted from the remote monitor client to theweb server. Information about the selected servers is received at theremote monitor client from the web server.

According to another embodiment of the invention, a remote monitoringsystem is provided. A server has stored therein a server application,which is adapted to be executed by the server. A plurality of wirelessnetworks, each of which is adapted to communicate messages between theclient device and the server and to support one or more wireless networkprotocols is provided. A protocol gateway encapsulates a fundamentalnetwork protocol, which underlies each of the one or more wirelessnetwork protocols. At least one message router routes the messagebetween the protocol gateway and the server. Means for providinginformation from at least one of the server, the protocol gateway, andthe message router to a remote monitor client are also provided.

The means for providing information can comprise at least one web servercommunicating with the remote monitor client and with at least one ofthe server, the protocol gateway, and the message router. Furthermore,the web server may include means for compiling a list of availableservers, protocol gateways, and message routers and providing this listto the remote monitor client. The means for providing can also includemeans for gathering requested information from at least one of theserver, the protocol gateway, and the message router and providing therequested information to the remote monitor client.

According to another embodiment of the invention, a computer useableinformation storage medium storing computer readable program code meansis provided. The code means causes a computer to perform the steps of:publishing a list of available servers to the remote monitor clients,receiving selected servers from the remote monitor clients, dynamicallygenerating information about the selected servers with the web server,and providing the dynamically generated information from the web serverto the remote monitor clients.

Thus, remote monitoring of servers in an intelligent messaging networkcan be accomplished. Logging and status information can be obtained atremote locations to monitor and improve the performance of theintelligent messaging network. Further features and advantages of theinvention, as well as the structure and operation of various exemplaryembodiments of the invention, are described in detail below withreference to the accompanying drawings. In the drawings, like referencenumbers generally indicate identical, functionally similar, and/orstructurally similar elements. The drawing in which an element firstappears is indicated by the leftmost digits in the correspondingreference number.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other features and advantages of the invention will beapparent from the following, more particular description of an exemplaryembodiment of the invention, as illustrated in the accompanyingdrawings.

FIG. 1A is a block diagram of an exemplary embodiment of a communicationsystem that advantageously incorporates a messaging system according tothe present invention;

FIG. 1B is a high level block diagram of an exemplary embodiment of thepresent invention including an exemplary protocol gateway coupled to anexemplary message router which is coupled to an exemplary back-endserver;

FIG. 1C is an exemplary embodiment illustrating messaging routingaccording to the present invention;

FIG. 1D is an exemplary embodiment illustrating a protocol gateway (PG)startup sequence according to the present invention;

FIG. 1E is an exemplary embodiment illustrating a message router (MR)startup sequence according to the present invention;

FIG. 1F is an exemplary embodiment illustrating a back end server (BES)startup sequence according to the present invention;

FIG. 2 is a block diagram of an exemplary embodiment of a redirectorthat interacts with a browser and the intelligent messaging network thatis part of the system of FIG. 1A;

FIG. 3 depicts an exemplary embodiment of the proprietary protocol stackof the present invention;

FIG. 4 is an exemplary embodiment of a flow diagram numericallydepicting a flow of messages that corresponds to an authenticationchallenge success;

FIG. 5 is an exemplary embodiment of a flow diagram numericallydepicting a flow of messages that corresponds to an authenticationchallenge failure;

FIG. 6A is an exemplary embodiment of a flow diagram numericallydepicting a flow of messages that corresponds to a client applicationrequest to Back-End Server;

FIG. 6B is an exemplary embodiment of a flow diagram numericallydepicting a flow of multi-segment messages that corresponds to a clientapplication request to a Back-End Server;

FIG. 7A is an exemplary embodiment of a flow diagram numericallydepicting a flow of messages that corresponds to a Back-End Serverresponse to client application;

FIG. 7B is an exemplary embodiment of a flow diagram numericallydepicting a flow of multi-segment messages that corresponds to aBack-End Server (BES) response to client application, or alternativelyan alert generated by the BES;

FIG. 8A is an exemplary embodiment of a flow diagram numericallydepicting a flow of messages that corresponds to a Back-End Server alertto client application;

FIG. 8B is an exemplary embodiment of a flow diagram depicting a flow ofmessages providing an exemplary hybrid alert to an alternate clientdevice according to the present invention;

FIG. 8C is an exemplary embodiment of a flow diagram depicting a flow ofmessages representing an exemplary request and alert that could giverise to sending of a hybrid alert according to FIG. 8B according to thepresent invention;

FIG. 9A is an exemplary embodiment of a remote monitoring system for anintelligent messaging network;

FIG. 9B is an exemplary embodiment of a flow diagram depictingcommunication flow in a remote monitoring system; and

FIG. 10 is an exemplary embodiment of a diagram illustrating anexemplary message header according to the present invention.

DETAILED DESCRIPTION OF AN EXEMPLARY EMBODIMENT OF THE INVENTION

A preferred embodiment of the invention is discussed in detail below.While specific implementations are discussed, it should be understoodthat this is done for illustration purposes only. A person skilled inthe relevant art will recognize that other components and configurationsmay be used without parting from the spirit and scope of the invention.

FIG. 1A depicts a block diagram of a communication system 100 thatadvantageously can incorporate the present invention including one ormore client devices 112 a-c, collectively referred to as client devices112. The client devices 112 can execute corresponding clientapplications, which can be developed to provide specific subscribersolutions. For example, service subscribers such as, e.g., client user102, as shown, can carry, e.g., Palm Pilot client devices, Windows CEbased client devices or other one-way or two-way messaging clientdevices 112 to, e.g., remain apprised of stock market activities andinitiate transactions while roaming within the coverage area of theirrespective wireless service providers.

As described in detail below, the communication system 100 can supportan intelligent messaging network architecture (hereafter referred to as“intelligent messaging network”) according to the present invention. Theintelligent messaging network advantageously can incorporate amiddleware service in accordance with the present invention that canallow for the development of client and server applications independentof the underlying network protocols and device configurations. The basicmiddleware services offered by the intelligent messaging networkarchitecture can include, e.g., client-server connectivity, platformtransparency, network transparency, application tool support (throughthe use of APIs), network management, interaction with other networkservices, scalability and high availability.

System Overview

FIG. 1A depicts an exemplary embodiment of the communication system 100including a detailed block diagram of the present invention. Thecommunication system 100, in an exemplary embodiment, can be configuredto support a wide variety of wired and wireless access network protocolsvia an access network 114. The access network 114 protocols can include,e.g., dial-up modem, analog cellular, digital cellular, cellular digitalpacket data (CDPD), Mobitex, RIM, Ardis, iDEN, personal communicationsystem (PCS)-code division multiple access (CDMA) or time divisionmultiple access (TDMA), global system for wireless messaging (GSM),two-way and one-way paging (e.g., ReFlex, Flex, etc.), as well asgeosynchronous earth orbit (GEO) or low earth orbit (LEO) satellitenetwork access protocols. The intelligent wireless messaging network ofthe present invention can provide network transparency to developers ofclient and server applications. As such, developers do not need toconcern themselves with implementation details of the underlying networkprotocols or with various platform specific encoding, such as, e.g.,big-endian and little-endian.

A number of the protocol gateways (PGs) 116 a, 116 b and 116 c,collectively PGs 116, can be configured to support a specific networkaccess protocol. The PGs 116, in an exemplary embodiment, can act as aninterface between a network 114 and wide-area/local-area networks(WANs/LANs) 118 a, and 118 b. The PGs 116 can provide the flexibility tosupport multiple present and future wireless access protocols such as,e.g., GPRS. Networks 118 collectively including networks 118 a and 118b, as shown, can be coupled to network 114 by, e.g., a router 114, andcan be protected from unauthorized access through a firewall 120.Networks 118 can include, e.g., a wide area network (WAN), local areanetwork (LAN), and/or the global Internet. Among other things, networks118 can include, e.g., one or more back-end servers (BESs) 122 a, 122 b,and 122 c, collectively BESs 122, that can run server applications thatcan communicate messages with client applications running on the clientdevices 112. Via one or more message routers (MRs) 124 a, 124 b, and 124c, collectively MRs 124, these messages can be routed between the BESs122 and the PGs 116, and other network components. From the BESs 122,messages can be transmitted or delivered to, e.g., a content provider140. A specific type of BES shown as an HTTP Proxy BES 132 can be usedto send messages to an Internet server 142 such as a web server. Itshould be noted that although the present invention is described withreference to a specific exemplary architecture, a wide variety of WANsand LANs that can support wired and wireless environments are possible.

The PGs 116 can be responsible for sending and receiving applicationmessages between client applications and a BES 122 that can support theservice type of the application message. The message can be routed tothe BES 122 via the MR 124 as will described further below withreference to FIG. 1C. For each network access protocol that theintelligent messaging network supports, a corresponding PG 116 cansupport that network access protocol. PGs 116 can communicate directlywith one or more MRs 124 using, e.g., conventional TCP/IP communicationsor a modification of TCP/IP to address flow control between wireless andwireline networks. In an exemplary embodiment of the invention, the PGs116 can use clustering for, e.g., redundancy, scalability andload-balancing of incoming IP traffic across all the nodes within aconfigured cluster. In an exemplary embodiment, PGs 116 can provide loadbalancing by providing traffic to MRs 124 in, e.g., a round-robinfashion, which can, e.g., transmit to least recently used MR 124. Underthis arrangement, client applications can be configured to communicateto a single virtual IP address of the PG 116 cluster. Advantageously,this can provide the intelligent messaging network the flexibility todynamically start and stop the PGs 116 without disrupting service.Typically, the PGs 116 can run outside of the firewall 120. However, theintelligent messaging network architecture of the present invention doesnot preclude the PGs 116 from running inside an enterprise firewall 120.It will be apparent to those skilled in the art that alternativeconfigurations can also be used within the spirit and scope of thepresent invention.

The BESs 122 and MRs 124 can each have access to corresponding BES andMR databases (DBs) 126 and 128, respectively, which can store serverapplication and message routing parameters. Alternatively, a shareddatabase can be used to store information on an auxiliary memory devicesuch as, e.g., a storage area network (SAN). The BES DB 126 and MR DB128 can each maintain a common pool of information amongst the entiregroup of network servers. In an exemplary embodiment, this information,which can be independent of any specific messaging application, can bestored and accessed from a structured query language (SQL) database.

In order to assist network administrators in managing the intelligentmessaging network, the intelligent messaging network architecture canincorporate one or more simple network management protocol (SNMP)management consoles 130 a, 130 b, and 130 c, collectively SNMP console130, as the mechanism for network management. SNMP is a standard networkmanagement protocol widely used in conventional TCP/IP networks. Theconsole 130, e.g., can receive SNMP alerts. In an exemplary embodiment,a customer's SNMP console 130 can be “hooked” into, including such dataas might reside in, e.g., a management information base (MIB) 134 a. TheSNMP console 130 can be used to easily and effectively manage theintelligent messaging network of the present invention. In addition toproviding SNMP support, the intelligent messaging network can providenetwork administrators a tool to monitor the health of the network. AnSNMP console 130 can be placed in a network operations center (NOC) toadvantageously centrally manage the intelligent messaging network of thepresent invention.

An HTTP Redirector 106 can enable off-the-shelf web browsers such as,e.g., browser 104, to send and receive requests, such as, e.g.,hypertext transfer protocol (HTTP) requests, over the intelligentmessaging network. As described later, the HTTP Redirector 106 can workby intercepting HTTP requests from the browser 104 and can redirect themover the intelligent messaging network for fulfillment by an intelligentmessaging network HTTP proxy back end server 132 a, 132 b, or 132 c,collectively HTTP proxy back end servers (HBES) 132, which in turn canforward messages on to, e.g., other Internet servers 142. While theintelligent messaging network can provide a set of advanced services,the network can also offer support for external legacy services thatmight already be in use by an organization. By supporting other vendorservices such as, e.g. security, and databases, the intelligentmessaging network can fit into an existing legacy networkingenvironment, thereby allowing organizations to use their existingnetworking environment.

An Exemplary Implementation Embodiment of the Present Invention

In an exemplary implementation embodiment of the present invention, theIntelligent Messaging Network of the present invention can use an AetherIntelligent Messaging (AIM) Network (also referred to as AIM.net)developed by Aether Systems Inc., of Owings Mills, Md., U.S.A., theassignee of the present invention.

In an exemplary implementation embodiment, the BES 122 can be an AetherBack End Server (ABES) available from Aether Systems Inc., of OwingsMills. Md., U.S.A.

In an exemplary implementation embodiment, the PG 116 can be an AetherProtocol Gateway (APG), also previously referred to as a frontend server(FES), available from Aether Systems Inc., of Owings Mills, Md., U.S.A.

In an exemplary implementation embodiment, the MR 124 can be an AetherMessage Router (AMR) available from Aether Systems Inc., of OwingsMills, Md., U.S.A.

An exemplary embodiment of the MR DB 128 is an AIM database availablefrom Aether Systems, Inc. of Owings Mills, Md., U.S.A.

In an exemplary implementation embodiment, the SNMP Console 130 can bean Aether SNMP Network Management Console available from Aether SystemsInc., of Owings Mills, Md., U.S.A., which can include an SNMP compliantnetwork management application and hardware system platform.

In an exemplary implementation embodiment, the HTTP Proxy Back EndServer 132 can be an Aether HTTP Proxy Back End Server available fromAether Systems Inc., of Owings Mills, Md., U.S.A.

It will be apparent to those skilled in the relevant art thatalternative implementations incorporating alternative or additionalcomponents, systems, operating systems, and applications could also beused within the spirit and scope of the present invention.

Software Development Environment

The intelligent messaging network, in an exemplary embodiment, canprovide multiple software development kits (SDKs) to assist, e.g.,engineers in developing client and server applications. The SDKs cancontain a consistent set of APIs and a set of platform specificlibraries for all intelligent messaging network supported platforms andnetworks. In addition to the SDKs, the intelligent messaging network canprovide developers a resource kit including a set of tools to assist thedevelopers when designing, implementing, and testing their client andserver applications.

As described later in detail, the intelligent messaging network canprovide, in an exemplary embodiment, a mobile client and server SDKenvironment to assist engineers developing client applications and BESs122. The SDKs can provide an easy to use API and a set of platformspecific libraries to perform, e.g., compression, network managementservices, server-to-server communication, serverregistration/de-registration, and reliable message transport services.

I. Common Network Services

In an exemplary embodiment, all of the servers, PGs 116, MRs 124, BESs122 can use, e.g., Windows NT 4.0 as their operating system availablefrom Microsoft Corporation of Redmond, Wash., U.S.A. Althoughalternative operating systems can be used in alternate embodiments, aswill be apparent to those skilled in the art, functionality of thepresent invention will be described in an exemplary Windows NT v.4.0environment. All the servers provide a set of common services,including, e.g.:

network management;

NT event logging;

message trace logging;

run as NT services;

server registration;

server de-registration; and

server-to-server TCP/IP communication.

The intelligent messaging network server SDK can encapsulate theimplementation of these core functions via application programminginterfaces (APIs) to insulate application developers from the hardware,software and protocol details of the underlying platforms. Providedbelow is a description of exemplary common services.

A. Network Management Service

All intelligent messaging network servers can support the standard SNMPGET, SET, and GET NEXT operations. In addition, the intelligentmessaging network servers can generate SNMP traps for notifying anetwork administrator of a critical event. The intelligent messagingnetwork Server SDK can provide a common MIB, for basic control andstatus-handling that is shared by all the intelligent messaging networkservers. In addition, the intelligent messaging network server SDK canprovide a MIB for each supported server type (i.e. PG 116, MR 124, HTTPProxy Back End Server 132, and BES 122). Developers developing BESs 122can define custom MIBs to support functions specific to theirapplication needs and can register the custom MIBs in a registered MIBsdatabase 134. Registration of a custom MIB with the SNMP console 130 canbe encapsulated by a set of network management APIs provided by theintelligent messaging network server SDK.

B. NT Event Logging Service

All intelligent messaging network servers can log critical information(e.g., start/stop time, and critical errors) to the NT event log on acorresponding platform on which they are running. Developers developingBESs 122 can log application specific events to the NT event log viaAPIs provided by the intelligent messaging network server SDK.

C. Message Trace Logging Service

All intelligent messaging network servers can optionally log inbound,outbound, and system events on the platform on which they are running.Developers developing BESs 122 can log application specific informationto an application-info-log via APIs provided by the intelligentmessaging network server SDK. In this way, developers are not requiredto know the implementation details of how to log a message to theinbound, outbound, or system-info-logs.

D. Run as NT Service

In an exemplary embodiment of the invention, all intelligent messagingnetwork servers can run as NT services. Rather than having each serverimplement the necessary code to run as an NT service, a utility programcalled AimServiceAny can be that can wrap NT service functionalityaround each intelligent messaging network server executable. Thebenefits of running a server as an NT service can include the followingadvantages:

-   -   Automatic Start on Reboot—Conventionally, when a reboot of a        machine is necessary, the user re-booting can also log on and        manually start any servers that need to be running on the        machine. With an AutoStart function provided by the        AimServiceAny, each intelligent messaging network server running        as an NT service can automatically restart before the user logs        on. This feature can be useful if, for example, the platform        reboots at night without human intervention.    -   No NT Logon Required to Run—As an added security measure,        intelligent messaging network servers can run without having        anyone logged onto the machine and, thus, can prevent        unauthorized users from accessing the platform and the servers.    -   Network Management Mechanism—In addition to SNMP, running as an        NT service provides an additional simple network management        capability by using a remote SvrMgr utility provided on all NT        servers to monitor and start/stop intelligent messaging network        services running anywhere on the network.    -   Startup Dependencies—An NT service can depend on the presence of        other services before it is allowed to start (e.g. some        intelligent messaging network servers depend on the fact that an        SQL database server is running as well as possible        server-to-server dependencies).

E. A Mechanism for Providing Discovery Services for Servers DuringStartup Sequence

The intelligent messaging network can include various servers including,e.g., the following:

1. PGs 116:

2. MRs 124; and

3. BESs 122.

The simplest instance of an intelligent messaging network can include aserver of each of the three types coupled together as depicted in theexemplary embodiment of FIG. 1B.

FIG. 1B depicts, in an exemplary embodiment, a high level block diagram136 of the present invention including, e.g., one or more PGs 116 a-ccoupled to one or more MRs 124 a-c, which are in turn, coupled to one ormore BESs 122 a-c.

Each server-to-server connection can include a TCP connection. Asindicated in block diagram 136, PGs 116 a-c can be coupled to MRs 124a-c; MRs 124 a-c can be coupled to PGs 116 a-c and BESs 122 a-c (orHBESs 132 a-c); and BESs 122 a-c (or HBESs 132 a-c) can be coupled toMRs 124 a-c. Server startup logic can include, e.g., starting theservers 116, 122, and 124 in any order as each server can attempt tofind the server(s) of the required type to which it is to be coupled.The server start sequence, in an exemplary embodiment, can proceed asfollows:

-   -   1. Upon start-up, an intelligent messaging network server 116,        122 and 124 can create a TCP “listener” socket. The TCP listener        socket accepts connection requests from other intelligent        messaging network servers 116, 122 and 124.    -   2. The intelligent messaging network server then registers the        following information about the server in the intelligent        messaging network MR database 128:        -   The IP address of the server and the port that the server is            listening on for new connections;        -   The server's intelligent messaging network Domain; and            -   An intelligent messaging network Domain is a text string                (e.g. “MyTestDomain”) that allows multiple intelligent                messaging networks to run on the same physical network                without interfering with each other. An intelligent                messaging network server can only connect to other                intelligent messaging network servers in the same                domain.        -   The server's server type e.g.: PG 116, MR 124, or BES 122.    -   3. After the server registers itself in the MR database 128, the        registering server can obtain a unique database registration        identifier (ID) and then can search the MR database 128 for        other registered servers in the server's intelligent messaging        network domain and of the appropriate type; e.g., PGs 116 can        search for MRs 124 in their domain, MRs 124 can search for PGs        116 and BESs 122, BESs 122 can search for MRs 124.    -   4. In the simplest intelligent messaging network, each server        116, 122 and 124 can find one instance of each peer type to        which it connects. However, the intelligent messaging network        can allow multiple servers of each type to run within a domain        in order to improve performance and redundancy. For example, in        an exemplary embodiment, if there are 2 PGs 116 and 3 MRs 124,        each PG 116 can be coupled to each of the MRs 124. For each peer        server it finds in the database 128, the intelligent messaging        network server can attempt to couple itself to that server on        the peer server's TCP listener socket.    -   5. If the intelligent messaging network server 116, 122 and 124        successfully connects to a peer, establishing a TCP connection,        the two coupled servers can then perform an intelligent        messaging network “connection handshake” in order to verify the        validity of the connection. The connection handshake can include        the following sequence:        -   a) The connecting server can send an intelligent messaging            network ServerConnect message to the peer server. This            message can contain the connecting server's unique database            registration ID (obtained when the server first registered            in the database, see step 2 above). The connecting server            can then wait a specified amount of time for a reply from            the peer server.        -   b) The peer server can receive the intelligent messaging            network “connection message” and can verify that the version            included as part of the intelligent messaging network            message is compatible with its own communications version            and that the message is indeed an intelligent messaging            network connection message. If the version is incorrect or            the message is not a connection message, the peer server can            terminate the TCP connection. If the peer server accepts the            connection message it can send an intelligent messaging            network connection message back to the connector in reply.        -   c) When the connecting server receives a “connection reply            message” the connecting server can also verify the message            version and type and can either keep the connection open, or            close the connection if, e.g., the version and type            verification fail.        -   d) If the connecting server does not receive an intelligent            messaging network connection reply message within the            specified time window, the connecting server can assume that            the peer server is, e.g., not a valid intelligent messaging            network server, or is functioning improperly and so it can            close the TCP connection to the peer server.

FIG. 1C is described below after FIG. 1F relating to MR 124.

PG Startup Sequence

FIG. 1D depicts a block diagram 144 illustrating an exemplary embodimentof discovery services message flow for a PG 116 startup sequence. Thediscovery service flow can begin with step 146.

In step 146, the PG 116 can use registration services provided by, e.g.,the intelligent messaging network server SDK to register the PG 116 withthe intelligent messaging network by adding an entry to aRegisteredServers table in the MR database 128.

From step 146 flow can continue with step 148.

In step 148, the PG 116 can use registration services provided by theintelligent messaging network server SDK to enumerate the list of allthe MRs 124 registered with the intelligent messaging network in, e.g.,the same domain. From step 148, flow can continue with step 150.

In step 150, using an IP address and listener port for each of the MRs124, the PG 116 can use communication services provided by theintelligent messaging network server SDK to establish and manage aTCP/IP connection with each of the MRs 124 contained in the enumeratedlist. When a PG 116 couples itself to the MR 124, the MR 124 can add thePG 116 to its RegisteredServers cache and can begin to start forwardingmessages to the PG 116. If a connection attempt fails, the PG 116 canre-attempt to connect to the MR 124, according to an exemplaryembodiment of the present invention.

MR Startup Sequence

FIG. 1E depicts a block diagram 152 illustrating an exemplary embodimentof discovery services message flow for a MR 124 startup sequence. Thediscovery service flow can begin with step 154.

In step 154, the MR 124 can use registration services provided by theintelligent messaging network server SDK to register itself with theintelligent messaging network by adding an entry to theRegisteredServers table in the MR database 128. It will be apparent tothose skilled in the art that an alternative database could be used.From step 154, diagram 152 can continue with step 156.

In step 156, the MR 124 can use registration services provided by theintelligent messaging network server SDK to enumerate a list of, e.g.,all PGs 116 and BESs 122 registered with the intelligent messagingnetwork. From step 156, diagram 152 can continue with step 158.

In step 158, using the IP Address and listener port for each PG 116, theMR 124 can use communication services provided by the intelligentmessaging network server SDK to establish and manage a TCP/IP connectionwith, e.g., each PG 116 contained in the enumerated list. When a MR 124couples to a PG 116, the PG 116 can add the MR 124 to its ServerConnections cache and can begin to start forwarding messages to theMessage Router. From step 158, diagram 152 can continue with step 160.

In step 160, using the IP address and listener port for each BES 122,the MR 124 can uses communication services provided by the intelligentmessaging network server SDK to establish and manage a TCP/IP connectionwith each BES 122 contained in the enumerated list. When a MR 124couples to a BES 122, the BES 122 can add the MR 124 to its ServerConnections cache and can begin to start forwarding messages to the MR124.

BES Startup Sequence

FIG. 1F depicts a block diagram 162 illustrating an exemplary embodimentof discovery services message flow for a BES 122 startup sequence. Thediscovery service flow can begin with step 164.

In step 164, the BES 122 can use the registration services provided bythe intelligent messaging network server SDK to register itself with theintelligent messaging network by adding an entry to theRegisteredServers table in the MR database 128. From step 164, diagram162 can continue with step 166.

In step 166, the BES 122 can use registration services provided by theintelligent messaging network server SDK to enumerate the list of, e.g.,all MRs 124 registered with the intelligent messaging network. From step166, diagram 162 can continue with step 168.

In step 168, using the IP address and listener port for each MR 124, theBES 122 can use the communication services provided by the intelligentmessaging network server SDK to establish and manage a TCP/IP connectionwith each MR 124 contained in the enumerated list. When a BES 122 cancouple to a MR 124, the MR 124 can add the BES 122 to itsRegisteredServers cache and can begin to start forwarding messages tothe BES 122. If the connection attempt fails, the BES 122 can reattemptto connect to the MR 124.

F. Server Connection Race Condition Handling

If two peer intelligent messaging network servers are started atapproximately the same time, it is possible that each will attempt toconnect to the other, thus establishing two connections between themrather than a desired single connection. The possibility of collidingconnection requests is the reason that during the connection handshake,the servers exchange unique database registration IDs. Each server canuse the unique database registration ID to keep track of which serversit is already connected to, so that if server A establishes a connectionto server B, and due to race conditions server B immediately establishesanother connection to server A, server A can use the unique databaseregistration ID passed by server B to realize that it already has aconnection to server B and thus can drop the new connection.

G. Server Registration Service

When an intelligent messaging network server is started, it can registeritself with the network by adding an entry to a RegisteredServers tablein the intelligent messaging network MR database 128. This can enableother intelligent messaging network servers to locate one another on thenetwork. An API provided by the intelligent messaging network server SDKcan allow for registering the following server attributes in theintelligent messaging network MR database 128:

-   -   Server Class—PG 116, BES 122, and MR 124;    -   Server Type—PGs 116 types can include CDPD, Mobitex and ISP        dialup. BES 122 types can depend on the server application;    -   Packet Header Version—can indicates the version of the packet        header that the server supports; and    -   IP Address and Listener Port—can indicate the IP address and the        listener port number to be connected to by other servers in        order to communicate with this server.

H. Server De-Registration Service

When an intelligent messaging network server is stopped, it cande-register itself from the network by removing its entry from theRegisterServers table in the intelligent messaging network MR database128. An API can be provided by the intelligent messaging network serverSDK to de-register a server in the intelligent messaging network MRdatabase 128.

I. Server-to-Server TCP/IP Communications Service

In an exemplary embodiment of the invention, intelligent messagingnetwork servers can communicate with each other over a TCP/IP socketconnection. APIs provided by the intelligent messaging network servercan encapsulate the creation, management, and sending/receiving of dataover the socket connection.

II. Server-Specific Services

In addition to the above-described common set of services, each servercan also provide additional services that can be specific to thefunctionality of the server. Thus, in an exemplary embodiment, theintelligent messaging network architecture can include various coresoftware components that can run on, e.g.:

PG 116;

MR 124;

BES 122;

HTTP Proxy Back End Server 132; and

SNMP Management Console 130.

A. Protocol Gateway PGs Operation and Services

Using the registration services provided by the intelligent messagingnetwork server SDK, the PGs 116 can follow a predefined start upsequence to register itself with the intelligent messaging network. EachPG 116 can add an entry to the RegisteredServers table in theintelligent messaging network MR database 128 and can enumerate the listof all MRs 124 registered with the network in the same domain. Based onthe IP address and listener socket for each MR 124, the PG 116 canestablish and manage a TCP/IP connection with each MR 124 contained inthe enumerated list. When a PG 116 connects to an MR 124, the MR 124 canadd the PG 116 to its RegisteredServers cache and can begin forwardingmessages to the PG 116. If, however, the connection attempt fails (e.g.,there is a timeout), the PG 116 can re-attempt to connect to the MR 124after a configurable time period.

In addition to the above-described common services, the PGs 116 can beresponsible for supporting the following specific services:

1. Encapsulate the Network Communications Protocol

Each PG 116 can encapsulate the underlying wireless network accessprotocol so that it is transparent to MR 124 and BESs 122. As a result,when the MR 124 receives a message from a PG 116, it is unaware of theunderlying network access protocol used for communicating the message.

2. Message Segmentation

All messages to be transmitted over the network that exceed a predefinedsegment size can be segmented into multiple message segments.

3. Message Re-Assembly

All incoming message segments (except the last segment to complete themessage) received (including duplicate segments) can be immediatelyacknowledged back to the peer wireless protocol layer and can be queuedpending receipt of all message segments via an inbound message map. Whenthe last segment to complete the message is received, the PG 116 doesnot immediately send an acknowledgment to the peer wireless protocollayer. Instead, the message segments can be assembled into a completemessage, which can be forwarded to an appropriate BES 122 via an MR 124.When the BES 122 successfully receives the message and acknowledges thesame to the PG 116 via MR 124, then the PG 116 can acknowledge the lastsegment received thus completing the acknowledgment of the entiremessage. An inbound message map can manage a separate inbound messagemap for each unique link station ID of a sender.

4. Message Segment Duplication Detection

When a message segment has been received for a segmented message, the PG116 can check to make sure the message segment has not been alreadyreceived (i.e., a duplicate message segment). If the message segment isa duplicate, the segment can be acknowledged to the peer wirelessprotocol layer, discarded and conditionally logged.

5. Message Duplication Detection

When all message segments have been received for a message, the segmentscan be assembled into a complete message. If the message ID of theassembled message has been already received (duplicate message), thenthe message can be acknowledged to a corresponding peer wirelessprotocol layer, discarded and conditionally logged. Each PG 116 can keeptrack of the last n message IDs received for each unique link stationID.

6. Message Pacing/Message Retries/Message Time Outs

Any message that is bound for a client device 112 can be segmented intoa number of segments greater than a segmented pacing threshold and canbe sent at a pacing interval. The threshold and interval can beconfigurable prior to a gateway protocol startup. Each PG 116 canautomatically retransmit any message segment transmitted over thenetwork that is not acknowledged by a corresponding peer wirelessprotocol layer within a configurable amount of time. The PG 116 canretry a configured number of times before notifying a BES 122 that themessage could not be delivered to a client application.

7. Forwarding of Ack/Nack Messages

When a message segment is transmitted over the network 212, each PG 116can retain knowledge of all outstanding message segments pendingacknowledgment (message segments that have not been acknowledged by thepeer wireless protocol layer) via a pending acknowledgment map. Thepending acknowledgment map can maintain information pertaining tomessage segments that have been successfully transmitted and are pendingacknowledgment from the peer wireless protocol layer. If anacknowledgment (positive or negative) is received for a message segmentthat is not pending acknowledgment, the segment can be discarded andconditionally logged.

When all message segments have been positively acknowledged by the peerwireless protocol layer, the PG 116 can sen, as shown in step 5 of FIG.7, an ACK control message to the BES 122 via MR 124 (provided that theBES 122 has requested such notification) to indicate the message hasbeen successfully delivered to the client application. If the number oftransmission attempts for the message segment exceeds a configurablenumber of retry attempts, the PG 116 can send an NACK control message tothe BES 122 to indicate that the message could not be delivered to theclient application.

B. Message Router MR Operation and Services

Each MR 124 can communicate with the PGs 116 and BESs 122. Upon startup, the MR 124 can use the registration services provided by theintelligent messaging network server SDK to register the MR 124 itselfwith the intelligent messaging network by adding an entry to theRegisteredServers table in the MR database 128. The MR 124 can also usethe registration services to enumerate the list of all the PGs 116 andBESs 122 that are registered with the intelligent messaging network.Using the IP address and listener port or socket for each PG 116, the MR124 can establish and manage a TCP/IP connection with each PG 116contained in the enumerated list. When an MR 124 connects to a PG 116,the PG 116 can add the MR 124 to its Server Connections cache and canbegin to start forwarding messages to the MR 124. Based on the IPaddress and listener port for each BES 122, the MR 124 can alsoestablish and manage a TCP/IP connection with each BES 122 contained inthe enumerated list. See FIG. 1C. When a MR 124 connects to a BES 122,the BES 122 can also add the MR 124 to its Server Connections cache andcan begin to start forwarding messages to the MR 124.

Each MR 124 can also use the registration services provided by theintelligent messaging network server SDK to de-register itself from theintelligent messaging network by removing its entry from theRegisteredServers table in the MR database 128. The MR 124 can close theTCP/IP connection with each PG 116. Each PG 116 can also remove the MR124 from its Server Connections cache and can immediately stopforwarding messages to the terminating MR 124. Then, the MR 124 canclean up any previously allocated resources and can terminate.

FIG. 1C depicts an exemplary embodiment illustrating messaging routingaccording to the present invention. FIG. 1C illustrates a client user102 using a client device 112 can attempt to communicate via wirelessnetwork 108 and network 114 to resources coupled to PG 116. As shown,BESs 122 a, 122 b and 122 c can have already registered upon boot withMRDB 128 of MR 124. Advantageously, according to the present invention,routing can be based on content instead of address. Registration ordiscovery can include a providing server identifier (ID), a servicetype, and a message type supported by the particular BES 122. MR 124 canload into the cache of MR 124, the registration information about BESs122.

MRs 124 and BESs 122 can communicate via a TCP/IP connection. As shown.BES 122 a can be registered for service type 7 and message type 5. BES122 b can be registered for service type 7 and all message types asillustrated by an asterisk (*) wildcard character. Each BES can have aunique server ID and service type combination. The only server ID thatcan be shared is 0 (zero).

The client device 112 can communicate with PG 116 and can send a messageincluding a unique message key. The unique message key can include, inan exemplary embodiment, a server identifier (ID), a service type and amessage type, as shown. The PG 116 can provide the MR 124 the messageover network 118 b.

PG 116, in an exemplary embodiment, can route to a least recently usedMR 124, providing a round-robin load balancing function. In an exemplaryembodiment, redundancy can be provided by using, e.g., multiple PGs 116and multiple MRs 124. Similarly, when an MR 124 has a message to routeto a PG, in the case of an alert or a response, the MR 124 can similarlyuse a round-robin load balancing method to route the message to a leastrecently used PG 116 supporting the protocol of the client device 112associated with the message.

Also, MR 124 can route a message received from the PG 116, to a BES 122or HBES 132. MR 124 can route the message, in an exemplary embodiment,according to a set of semantic rules. In an exemplary embodiment, themessage can be routed to the BES 122 which most specifically correspondsto the contents of the message key. In an exemplary embodiment if morethan one BES 122 corresponds specifically to the message key, the leastrecently used BES 122 can be used by checking a time stamp identifyingthe last access to the BES 122.

As an illustrative example, suppose client device 112 sends a messagecontaining a message key {server ID=0; service type=7; and messagetype=5} to a BES 122. In the exemplary illustration, PG 116 wouldforward the message to the least recently used MR 124. MR 124 could lookat the message key {0, 7, 5} to determine how to route the message.Based on the example registrations described above for BES 122 a {0, 7,5}; BES 122 b {0, 7, *}; and BES 122 c {1, 7, *}, MR 124 could route themessage to BES 122 a since the BES 122 a most specifically correspondedto the message key by having the exact service type and message type asthe message key. It is important to note that BES 122 b with a wild cardasterisk for supported message type could also support the message ifBES 122 a was not available. The semantic rules could use the BES 122 bas an alternative routing destination, if BES 122 c is unavailable.

For purposes of sending follow-on messages to a particular BES 122, inan exemplary embodiment, a specific server ID can be placed in amessage. In an exemplary embodiment, only one BES 122 will have aspecific combination of server ID and service type.

In addition to the common services that all intelligent messagingnetwork servers support, the MRs 124 are responsible for supporting thefollowing specific services:

1. MR Message Authentication Service

The MR 124 can be responsible for determining that the sender of amessage is an authorized customer of the intelligent messaging network.When the source of a message is a client device 112, the MR 124 can usethe device's source address (e.g., IP address or Mobitex MAN number) ofthe client device 112 as the means of identifying authorized access.

When each MR 124 receives a client message, it can check the deviceaddress against a local cache of authorized devices 112. If the sourceaddress is not found locally, the MR 124 can then check the MR DB 128.If the device address is an authorized client device 112, in anexemplary embodiment, and the customer has permission rights to therequested service type, and the requested service type is not in use bythe customer's account with a different source address, the MR 124 cancache the device address, customer identifier, and requested servicetype to ensure fast authentication of additional messages from the samesource. Then, the message can be considered authentic and can beforwarded to the proper BES 122. Each MR 124 also can pass the customeridentifier to the BES 122 to use as a key to search for customerspecific information.

In order to support dial-up access, in an exemplary embodiment, messageauthentication based on the device's source address is not used, becauseduring a dial-up access, the source address that can be seen by an MR124 is the IP Address of the ISP provider. Each subscriber that desireswire-line access can have a User ID and Password, which can be selectedby the subscriber at the time they subscribe to a service, and can besaved as part of the MR DB 128.

Each MR 124 can initially follow the same procedure to authenticate adial-up message as it does when authenticating a wireless message.However, in case a message is received from a dial-up connection, the MR124 can issue an authentication challenge to the message source. Onreceiving the challenge, the client application can prompt the user 102to enter the user ID and password of the user 102, which can beforwarded (encrypted) to the MR 124 as an authentication request and canproceed with authentication process.

Once a message source has been authenticated, the MR 124 can check theservice type and source address of subsequent messages against itsauthentication cache and can allow/disallow the message as appropriate.Preferably, in an exemplary embodiment, the MR 124 does not keep thecached mapping between a source address and valid customer indefinitely.A configurable timeout period may be specified, after which cachedentries can be removed. The timeout interval can be the length of timethat has passed between successive messages from a cached client device112. When a client device 112 times out due to inactivity, the MR 124can remove it from its cache. For dial-up devices, the MR 124 can alsodecrement a device's authentication count within the intelligentmessaging network MR database 128. The authentication count can indicatehow many other MRs 124 have heard from the client device 112. When adial-up device's authentication count drops to zero, the device addresscan be removed from the MR DB 128.

2. MR Client Message Routing Service

According to an exemplary embodiment of the invention, there can beseveral ways in which an MR 124 can route a client message to a BES 122,including, e.g.:

Indirect Routing—via an indirect routing table that can map message keys(service type and message ID) to a registered BES 122 that supports themessage key; and

Direct Routing—via targeting messages at a specific BES 122.

The form of routing can be determined based on the contents of anintelligent messaging message header. The intelligent messaging messageheader or message key can be pre-fixed to every application message.

The intelligent messaging message header can contain the followingfields, e.g.:

a 1-byte Server ID that can identify a specific server of the givenservice type. The value 0 can be reserved to indicate that indirectrouting is desired. A non-zero value can indicate that the message isdirected at a specific BES 122;

a 12-bit Service Type Identifier, which can be used by both indirect anddirect routing, can identify the type of service (e.g., MarketClip, FX,etc.) associated with the messages; and

a 12-bit Message Type Identifier that can uniquely identify the messagewithin the context of the specified service type required for directrouting.

a. Indirect Routing

When an MR 124 receives an incoming message from a client application,it can check the Server ID field contained in the intelligent messagingmessage header portion of the message. If the Server ID field of theintelligent messaging message header is zero, the MR 124 can route themessage to the proper BES 122 by consulting a routing table that can mapmessage keys (Service Type and Message ID) to the IP address of one ormore connected BESs 122 a-c as described above with reference to FIG.1C.

During server registration, all BESs 122 can be required to register alist of supported message keys. To minimize the number of entries thatare made in the routing table, if a given BES 122 supports the majorityof messages for a specific Service Type, it need only register a singleroot message key including only the Service Type. The small subset ofservice messages not supported by that BES 122 would be registered asindividual message keys by a different BES 122 of the same Service Type.The MR 124 can route messages based on the most specific key value(Service Type, Server ID, and Message ID) found in the table. If nospecific mapping is found, the MR 124 can use the Service Type portionof the key to look for root message entries. If the MR 124 locates morethan one BES 122 that satisfies the message key match, it can use around-robin scheduling procedure to pick which target BES 122 to routeto. For example, the timestamp of last access of the BES can beconsulted to determine a least recently used BES 122.

Consider, e.g., two third party services, MarketClip and FX, Reuters®news service solutions for real-time reporting on equities and foreignexchanges, with messages for each application supported by acorresponding BES 122. Under the configuration of the invention, eachapplication BES 122 could only have to register its root service type(e.g., MktMon or FX) in order for its messages or responses for clientdevices 112 to be routed correctly by the MR 124. Suppose that two BESs122 currently support news requests independently of one another (i.e.there is no common news BES 122 that both of them use), but a separatenews BES 122 can be created to handle ALL news requests. Ideally, no newsoftware should be sent to service providers so that all future newsmessages (for either application) are tagged to go to the new newsserver. Rather, the new news BES 122, upon registration, can add thespecific news message keys previously handled by the MarketClip and FXBESs 122 to the MRs 124 message routing table.

It should be noted that the original BESs 122 do not need to changebecause the news BES 122 message keys can contain the service types andmessage IDs specific to the two applications. Each MR 124 can do itsprimary routing based on the more specific table entries, the same newsmessages that would have formerly been routed to the two BESs 122, couldget routed to the new news BES 122. Thus, the BESs 122 can be designedaround specific services, rather than a suite of services that comprisean application, some of which may be common to other applications. Underthis arrangement, overall response performance can improve as specificservices are assigned to their own BES 122. This is because a clientapplication not using a given service does not have to wait, while theBES 122 is accessing process requests for a different service.

b. Direct Routing

BESs 122 that can maintain state information about a particular clientdevice 112 can often require direct routing. For a client to ensure thata message reaches a specific BES 122, the intelligent messaging networkmessage header portion of the message can contain a non-zero value inthe Server ID field. When an MR 124 sees a non-zero value in the ServerID field, it can route the message to the proper BES 122 by consulting arouting table that maps server keys {Service Type, Message ID, ServerID} to the IP address of a connected BES 122.

Specifying a Server ID alone can be not sufficient to ensure that themessage is delivered to the proper BES 122. Even when using directrouting, a BES 122 can register the service types and message IDs it canhandle; and the service type/message ID of a direct route message canmatch those types registered by the BES 122 with the specified ServerID. Management of BES 122 IDs can be the responsibility of theapplication. If an application runs more than one BES 122 with the sameServer ID, then messages with that Server ID can be routed to the BES122 whose message routing table can contain the most specific match withthe messages service type and Message ID. If two BESs 122 can map thesame Server ID, Service Type, and Message ID, then, as in indirectrouting, the MR 124 can use round robin scheduling to pick a target BES122.

A BES 122 may use both direct and indirect routing on an as neededbasis. To illustrate this, consider a BES 122 that for the most part isstateless, but has one or two logical operations that can requireseveral targeted client/server messages to complete. If the BES 122 caninitiate an operation that can require a targeted response, it can placeits Server ID in the intelligent messaging network message headerportion of the message it sends to the client application. When theclient application responds, it uses the same Server ID in the responsemessage to assure that the response is sent to the original Server. Allother “stateless” messages can be sent with a Server ID of 0, so thatthey can be indirectly routed.

3. MR Back-End Server BES Message Routing Service

BES 122 messages sent to a client application can pass through the MR124. Each MR 124 can decide which PG 116 to which to forward themessage. The MR 124 can choose the proper PG 116 based on, e.g., thecommunications type (e.g., CDPD, Mobitex, ISP Dialup, etc.) used by asubscriber's service provider. The mapping of communication type toclient device address can be maintained by the MR 124 based on fixedentries in the MR DB 128 that can map source address of a client device112 or used ID and password to a specific communication type. Each PG116 can also indicate the communication type of the PG 116 during theserver registration process. If a PG 116 could not deliver a message tothe client application, the PG 116 can send a network controlnon-acknowledgement (NACK) message to the BES 122 that originated themessage, indicating that the message could not be delivered.

4. Send Via clientDeviceInfo

When a BES 122 sends a message to a client application in response to areceived request message, the client device address (referred to, as itsclientDeviceInfo), which is a part of the received request message, canbe known to the BES 122. In response, the BES 122 can provide theclientDeviceInfo as part of the AIMSvrPacket sent to the MR 124.Consequently, the MR 124 can then simply pass this information to theappropriate PG 116, which can then send the message to that clientdevice 112 address.

5. Send Via CustomerID

At times, a BES 122 may need to asynchronously send a message to asubscriber (e.g. MarketClip Alert). Since this message is not inresponse to an incoming client message, the clientDeviceInfo may not bereadily available to the BES 122. Rather than forcing the BES 122 tokeep a mapping between client identifiers and their LinkStationIDs, aBES 122 may send a message to a client based solely on the customer ID.In this case, the AIMSvrPacket sent to a MR 124 contains a NULLLinkStationID and a valid client ID. The receiving MR 124 can searchit's authenticated device cache for an active device associated with thespecified client ID and then can use the device's LinkStationID toforward the message to an appropriate PG 116.

C. Back-End Server BES Operation and Services

A BES 122 is an application specific server that can implement logic toprocess messages specific for that type of server. For example, an FXBES 122 can handle requests related to foreign exchange functions. A BES122 can communicate directly with one or more MR 124s. Typically, BESs122 can run behind the firewall 120. However, the intelligent messagingnetwork architecture cannot preclude BESs 122 from running outside thefirewall 120.

Excluding the application logic, which may be complex, the developmenteffort to implement a BES 122 can be relatively straightforward. Theintelligent messaging network Server SDK can encapsulate those functionsthat are common to all BES 122s, thereby insulating developers from,e.g., details of transport control, compression, registering andde-registering with the MR DB 128.

Similar to other servers, the BESs 122 can use the registration servicesprovided by the intelligent messaging network server SDK to registerthemselves with the intelligent messaging network by adding an entry tothe RegisteredServers table in the MR DB 128. Each BES 122 can establisha TCP/IP connection with each registered MR 124, using a correspondingIP address. When a BES 122 connects to an MR 124, the MR 124 can add theBES 122 to its RegisteredServers cache and can begin to start forwardingmessages to the BES 122. When de-registering itself from the network,each of the BESs 122 remove its entry from the RegisteredServers tablesin the intelligent messaging network MR database 128. The BES 122 cannotify each MR 124 of its impending shutdown. This can allow each MR 124to remove the BES 122 from its RegisteredServers cache and canimmediately stop forwarding messages to the terminating BES 122.

In addition to the common services, the BESs 122 can be responsible forsupporting the following specific functions:

1. Application Protocol Aware Service

From the perspective of the BES 122, the BES 122 can directly with aclient application. In reality, however, a BES 122 can communicate withone or more MRs 124. In the intelligent messaging network architecture,only the BESs 122 can have knowledge of the application content requiredto communicate with a client application.

2. Extended Intelligent Messaging Network Compression

In the exemplary embodiment, intelligent messaging network can providean Adaptive-Huffman base compression service. The intelligent messagingnetwork architecture can provide the necessary hooks to enable 3^(rd)party OEM compression mechanisms. If a BES 122 has specific compressionrequirements for its application data that are not addressed byintelligent messaging network supplied compression services, (i.e.Adaptive-Huffman); the BES 122 can be responsible for providing thecompression mechanism.

3. Security Services

The architecture can provide the necessary hooks to enable 3^(rd) partyOEM security mechanisms. If a BES 122 has specific security requirementsfor its application data, the BES 122 can be responsible for providingthe security mechanism.

4. Forwarding of Ack/Nack Messages

When a client message is delivered to the BES 122, the BES 122 can senda network control acknowledgement (ACK) message to a PG 116 thatoriginally received the message. When the PG 116 receives the networkcontrol ACK message from the BES 122, it can send a transport level ACKmessage to the client device's peer wireless protocol layer indicatingthat the message was delivered successfully to the BES 122.

III. Intelligent Messaging Network MR Database

In an exemplary embodiment of the present invention, an intelligentmessaging network database can use an AIM Database available from AetherSystems of Owings Mills, Md., U.S.A. which, can maintain a common poolof information between intelligent messaging network servers. Thisinformation, which is independent of any specific messaging application,can be stored and accessed from a SQL database known as, e.g., the MR DB128, or the BES DB 126. In an exemplary embodiment, the MR DB 128 can beshared by all intelligent messaging network servers 116, 122, and 124.The following sections describe the tables that comprise the intelligentmessaging network MR database 128 schema. It will be apparent to thoseskilled in the art that the schema could also be used for anotherdatabase, such as, e.g., BES DB 126.

1.1 Schema

1.1.1 ServiceTypes Table

The ServiceTypes table is a list of all the service types supported bythe intelligent messaging network.

ServiceTypes Table Column Name Type Description ServiceName varchar[30]Service Name TypeID int ID of the Service AllowMultiAccess bit True ifservice allows multiple device access from a single user, false if onlyallows single device access from single user concurrently1.1.2 RegisteredServers TableThe RegisteredServers table is used during the connection process andkeeps track of the location and type of all Servers currently running onthe Network. Access to this table is through the Server SDK.

RegisteredServers Table Column Name Type Description DbID long Unique DBID used for cross referencing ServiceName varchar[30] Server Name Classint Server Class e.g. FES (PG), BES, MR 124 etc SubClass int ServerSubclass e.g. CDPD, Mobitex, etc DeathCount int The number of timesconnecting Servers have failed to connect to the Server ServerId byteOptional ID used for Server-Specific Message Routing NetHdrVersion intNetwork header version supported by this Server. IP Address varchar[15]Network location of Server Port short Listener port Server monitors forconnection requests PortB short A second port the Server monitors Domainvarchar[20] Name of the Domain the Server is running in RegistrationFILETIME Date/Time when Server registered Time1.1.3 ServerMsgMap TableThe ServerMsgMap is accessed during Server Registration, MR 124 Start-UPand client Message Routing. This table maps a running Server to the setof Message's that should be routed to that Server. Access to this tableis through Intelligent messaging network Server SDK.

ServerMsgMap Table Column Name Type Description ServerDBID long Crossreference to DBID column in RegisteredServer Table ServiceType int Typeof Service message handled by this Server MessageID int MessageIdentifier of message handled by this Server ServerID byte Optional IDused for Server-Specific Message Routing1.1.4 AuthorizedUsers TableThe AuthorizedUsers table is accessed during Message authentication. Thetable contains a list of UserIDs/Passwords with authorized access to theintelligent messaging network Network. Access to this table is throughthe Server SDK.

AuthorizedUsers Table Column Name Type Description UserID varchar[25]Identifier chosen by the customer e.g. (rudy, RudyB etc). This is thelogin ID for ISP dial-up service. Password varchar[25] Customer PasswordAccountNo char[8] Customer Account Identifier CustomerID long UniqueCustomerID used for cross referencing1.1.5 AuthorizedDevices TableThe AuthorizedDevices table is accessed during message authentication.This table contains a list of device addresses with authorized access tothe intelligent messaging network Network. Entries may be permanent (aMobile client Device) or temporary (a Wire-line device). Access to thistable is through the intelligent messaging network Server.

AuthorizedDevices Table Column Name Type Description DevAddressvarchar[25] Mobile client device address (IP, MAN, etc) Wireline bit 0 =Mobile client, 1 = Wire-line CommType int Communication Type (CDPD,Mobitex, CDMA, etc) of the client device Authentication int No. of MRs124 currently aware of this Count device AccessFlag int Used to blockaccess for devices reported missing or stolen CustomerID long Crossreference to Customer ID in AuthenticatedUsers table Token long Tokenused for security with wireline devices1.1.6 UserRights TableThe UserRights table is accessed during message authentication. Thistable contains the service types an authorized user can access. Accessto this table is through the Server SDK.

UserRights Table Column Name Type Description CustomerID long Crossreference to CustomerID in AuthenticatedUsers table. ServiceType intService Type the Customer is authorized to use. Cross reference toTypeID in ServiceType table.1.1.7 ActiveUsers TableThe ActiveUsers table is accessed during message authentication. Thistable contains the list of active customer IDs and the services they areusing with a count of MRs 124 that have authenticated the account forthe service in use. The purpose of the table is to detect and preventmultiple devices from accessing a service with same customer ID when theAllowMultiAccess bit is “false.” Also, the table contains theLinkStationType and LinkStationID used by the customer so the MRs 124can support NULL LinkStationID from the BES 122. Access to this tablecan be through the intelligent messaging network server.

ActiveUsers Table Column Name Type Description CustomerID long Crossreference to CustomerID in AuthenticatedUsers table. ServiceType intService type in use by Account No MRCount byte Number of MRs 124 thathave authenticated the account for the service in use CommType smallintCommunication Type (CDPD, Mobitex, etc) of the client deviceLinkStationID varchar[25] IP/Port or Mobitex Address1.1.8 CommTypes TableThe CommTypes table is a list of all communication Protocols supportedby the intelligent messaging network.

CommTypes Table Column Name Type Description CommName varchar[25] Nameof the communication Protocol TypeID smallint Communication Type ID1.2 Stored SQL ProceduresSQL procedures are used to manage the database. The following is a listof definitions commonly used as parameters in the stored SQL procedures.CustomerID—The customer's unique identifier.UserId—The user Id is used to authenticate ISP dial-up access.Password—The password is used to authenticate dial-up access.Account/No—The account number can be both alpha and/or numeric and isfor customer service purposes.Service Type—The service type the customer is provisioned to access. Forexample, MarketClip, MarketTrader, etc.DeviceAddress—For CDPD devices, this is an IP address in dot notation.For Mobitex, this is a MAN number.CommType—The type of Network Protocol the client device is using toaccess the intelligent messaging network Network. For example, CDPD,Mobitex, CDMA.Device Type—The type of access to the intelligent messaging networkNetwork, either wireless or wireline.NotifyAMR—True to notify all MRs 124 and false to not notify.ReturnCode—The return code from the stored procedure.1.2.1 NewCustomer

This stored SQL procedure allows customer service to enter a newcustomer using a wireless CDPD device to the database. User Id andPassword are entered as NULL.

Input:

-   -   UserID (varchar[25])    -   Password (varchar[25])    -   DeviceAddress (varchar[25])    -   AccountNo (char[8])    -   ServiceType (int)        Output:    -   CustomerID (int)    -   ReturnCode (int)—0=Success, 1=Duplicate User ID, 2=Duplicate        device address.        1.2.2 DeleteCustomer        This stored SQL procedure allows customer service to delete a        customer from the database. This procedure also deletes any        devices used by the customer and services provisioned for the        customer.        Input:    -   CustomerID (int)        Output:    -   ReturnCode (int)—0=Success, 1=Invalid customer id.        1.2.3 AddUser        This stored SQL procedure allows customer service to add a user        id and password to the database.        Input:    -   UserId (varchar[25])    -   Password (varchar[25])    -   AccountNo (char[8])        Output:    -   CustomerID (int)    -   ReturnCode (int)—0=Success, 1=Duplicate user id.        1.2.4 DeleteUser        This stored SQL procedure allows customer service to delete a        customer from the database. This procedure also deletes any        devices used by the customer and services provisioned for the        customer.        Input:    -   CustomerID (int)        Output:    -   ReturnCode (int)—0=Success, 1=Invalid customer id.        1.2.5 Change Password        This stored SQL procedure allows customer service to change a        user's password in the database.        Input:    -   UserID (varchar[25])    -   Password (varchar[25])        Output:    -   ReturnCode (int)—0=Success, 1=Invalid UserID        1.2.6 AddUserRight        This stored SQL procedure allows customer service to add a user        access right to a customer defined in the database.        Input:    -   CustomerID (int)    -   ServiceType (int)        Output:    -   ReturnCode (int)—0=Success, 1=Invalid customer id, 2=Duplicate        entry        1.2.7 DeleteUserRight        This stored SQL procedure allows customer service to delete a        user access right from a customer defined in the database.        Input:    -   CustomerID (int)    -   ServiceType (int)        Output:    -   ReturnCode (int)—0=Success, 1=Invalid customer id, 2=Invalid        user right for the customer.        1.2.8 AddDevice        This stored SQL procedure allows customer service to associate a        device address to a defined customer in the database.        Input:    -   DeviceAddress (varchar[25])    -   Wireline (bit)—0=client, 1=wireline.    -   CommType (smallint)—1=CDPD, 2=Mobitex, 3=ISP Dial up    -   CustomerID (int)    -   Token (int)        Output:    -   ReturnCode (int)—0=Success, 1=Bad parameter, 2=Duplicate device        address, 3=invalid customer id, 4=Customer already has device        address.        1.2.9 DeleteDevice        This stored SQL procedure allows customer service to delete a        device address from a defined customer in the database.        Input:    -   DeviceAddress (varchar[25])        Output:    -   ReturnCode (int)—0=Success, 1=Device address not found        1.2.10 DeleteDeviceByCustiD        This stored SQL procedure allows customer service to        disassociate by deletion of ALL device addresses from a defined        customer in the database.        Input:    -   CustomerID (int)        Output:    -   ReturnCode (int)—0=Success, 1=No device address(es) to delete.        1.2.11 SuspendUser        This stored SQL procedure allows customer service to suspend a        user and all the user's device address' access to the        intelligent messaging network and notify all MRs 124 to remove        the device address from it's local cache. This mechanism is used        when a customer reports a lost or stolen client device.        Input:    -   CustomerID (int)        Output:    -   ReturnCode (int)—0=Success        1.2.12 ReactivateUser        This stored SQL procedure allows customer service to reactivate        a user and all the user's device address' access to the        intelligent messaging network.        Input:    -   CustomerID (int)        Output:    -   ReturnCode (int)—0=Success.        1.2.13 SuspendDevice        This stored SQL procedure allows customer service to suspend a        device address' access to the intelligent messaging network and        notify all MRs 124 to remove the device address from it's local        cache.        Input:    -   DeviceAddress (varchar[25])    -   NotifyAMR 24 (bit)—True to suspend the device address from all        MRs 124 memory, false not to.        Output:    -   ReturnCode (int)—0=Success, 1=Error creating Server Manager,        2=Error calling Server Manager.        1.2.14 ReactivateDevice        This stored SQL procedure allows customer service to reactivate        a device address' access to the intelligent messaging network.        Input:    -   DeviceAddress (varchar[25])        Output:    -   ReturnCode (int)—0=Success.        1.2.15 GetCustomerID        This stored SQL procedure allows customer service to get the        customer identifier associated with a device address.        Input:    -   DeviceAddress (varchar[25])        Output:    -   CustomerID (int)    -   ReturnCode (int)—0=Success, 1=Device address not found.        IV. HTTP Proxy Back End Server

Most industry standard browsers support the ability to be configured toaccess the Internet via a proxy server instead of communicating directlywith an HTTP Web Server. The Intelligent messaging network HTTP ProxyBack End Server 132 is responsible for handling incoming HTTP requests,sending the request over the Internet to the target Web HTTP Server, andtransmitting the response back to the client device. The Intelligentmessaging network HTTP Proxy Back End Server 132 supports variousversions of the HTTP protocol specification. The HTTP Proxy Back EndServer 132 is also responsible for communicating with a target HTTP WebServer. In order to handle each inbound HTTP request, the HTTP ProxyBack End Server 132 creates and manages a TCP/IP socket connection tothe target Web HTTP Server. When the HTTP Proxy Back End Server 132receives the response from the Web HTTP Server, it creates an HTTPresponse message and formats it for transmission back to the clientapplication running on a client device.

V. HTTP Redirector

Browsers 104 can typically communicate directly to an H Web Server viaTCP/IP. TCP/IP, however, is a chatty LAN protocol requiring significantoverhead that is not a cost effective way for browsing the Internetwirelessly. According to one embodiment of the invention, an HTTPRedirector 106 can intercept raw HTTP requests from the browser 104 andcan redirect the request over the intelligent messaging network forfulfillment by an HTTP Proxy Back End Server 132. When the HTTPRedirector receives a response from the HTTP Proxy Back End Server 132,it can simply pass the response to the browser 104 to process.

FIG. 2 illustrates a block diagram 200 of an exemplary embodiment of thepresent invention. Block diagram 200 illustrates an HTTP Redirector 106interacting with the browser 104 and intelligent messaging networknetwork. The HTTP Redirector 106 can act as a “client side” proxy serverallowing it to intercept Web browser HTTP requests. When communicatingover the wireless network, the HTTP Redirector 106 can take advantage ofthe optimized wireless protocol and compression services offered by theIntelligent messaging network and the protocol of the present invention.This results in significant byte savings when sending HTTP requests andreceiving HTTP responses over a wireless network. In the exemplaryembodiment, the HTTP Redirector can support browsers 104 such as, e.g.,Microsoft's Internet Explorer 4.0 and Netscape's Communicator 4.5browsers on the Windows 95, 98, NT, 2000 and Windows CE platforms.

As mentioned above, browsing the Internet using a standard version of aconventional browser 104 is not ideal in a wireless environment.Standard versions of browsers 104 send HTTP requests over TCP/IP, whichis a chatty LAN protocol. TCP/IP is not cost effective in terms ofbandwidth usage in a wireless environment. Furthermore, a standardversion of browser 104 can require an IP based network andconventionally does not work with non-IP based wireless networks such asMobitex. The redirector 106 can address these issues and can provide amethod of using a standard Web browser 104 in a wireless network.

Referring to FIG. 2, in an exemplary embodiment, browser 104 of a clientdevice 112 can typically allow access to resources such as, e.g., adestination Web server 210, such as an Internet server 142 a on anetwork 202, such as, e.g., the global Internet, through a Proxy IP/port204 instead of communicating directly with the destination Web server210. In the environment of the present invention, the Proxy IP/port 204can fulfill a request on behalf of the client device 112 to thedestination Web server 210. The redirector 106 can act as a“client-side” proxy. The HTTP Redirector 106 can sit on top of standardmobile libraries 208 provided by the intelligent messaging network.These mobile libraries 208 can be optimized for the specific wirelessprotocol supported by the specific client device 112 a-c.

The HTTP Redirector 106 can intercept all requests from browser 104. Theraw HTTP request can then be packaged into an intelligent messagingnetwork message and transmitted through the intelligent messagingnetwork 114 to the BES 122 a-c designed to handle HTTP requests.

The HTTP BES 132 can forward the request to a Web server of a contentprovider such as, e.g., destination web server 210, which can provide aresponse. The content provider can be a third party in an exemplaryembodiment. The communication to the content provider can occur via thenetwork 202 of FIG. 2. A network 212 depicted in FIG. 2 can include theintelligent messaging network of the present invention, e.g., theunderlying LAN network 118 a and b, the PGs 116, the firewall 120,router 110, and the MR 124.

When the HBES 132 receives the response from the destination Web server210, HBES 132, or BES 122 (not shown), can package the response into anintelligent messaging network message and can transmit the response backto the requesting client device 112 via the PG 116 via the MR 124.

When the message arrives at the client device 112, it can be passed upto the redirector 106 where the message can be unpacked from itsintelligent messaging network format into an HTTP response and can besent to the browser 104. The HTTP redirector 106 can maintain allconnections with the browser 104 throughout this process, so that fromthe perspective of the browser 104, the browser 104 appears to becommunicating directly to the Web server 210.

The mobile libraries 208 can be optimized for the underlying wirelessprotocol. The HTTP Redirector 106 can sit on top of the libraries 208providing the browser 104 with the same benefits without anymodifications to the browser 104. Since the HTTP Redirector 106 packagesHTTP requests and responses into intelligent messaging network messages,the raw payload of the messages can be compressed. Most conventional Webtraffic deals with straight text in the form of HTML, so the amount ofdata transmitted can be greatly reduced by using standard compressiontechniques. The compression techniques can result in an increase in datathroughput and a reduction of airtime.

In addition to compression, in an exemplary embodiment, performance canbe enhanced by the fact that TCP/IP is not used over the wirelessnetwork, where the SNTL transport protocol of the present invention israther used.

Turning briefly to FIG. 3, an exemplary embodiment of a networkcommunications layered architecture is depicted. FIG. 3 includes blockdiagram 300, which is described further below following the descriptionwith reference to FIG. 8A.

VI. Message Flow

The flow of any messages within the network can include authenticationby the MR 124 via authentication challenge success, failures, clientapplication request to BES 122, BES 122 response to client application,and BES 122 to client application.

FIG. 4 illustrates a flow diagram 400 depicting an exemplary embodimentof the present invention. Flow diagram 400 numerically depicts a flow ofmessages that corresponds to the authentication challenge success flow.Flow diagram 400 numerically shows message paths between a client device112 and an MR 124 including exemplary steps labeled by numbers 1-8, asfollows:

-   -   1. The client application can send an application request        message to the MR 124 (the PG 116 is not explicitly involved in        authentication), i.e., a device authentication;    -   2. The client application running on a client device may fail        the authentication of the MR 124;        -   There are several ways a client application running on a            client device can fail authentication. The MR 124 cannot            find the device address in its local cache or the            AuthorizedDevices table in the intelligent messaging network            MR database 128. The device's security token in the            LinkStationID is not the same as the device's security token            in the intelligent messaging network MR database 128. The            subscriber does not have user rights to the requested            service.    -   3. The MR 124 can send a negative acknowledgment (NACK) message        to the client application with the appropriate error code;    -   4. The client application can respond with an authentication        request message including an UserID, secure password, and the        requested service type to authenticate; i.e., reauthentication;    -   5. The MR 124 can check the UserID and password against the        AuthorizedUsers in the MR DB 128;        -   If the UserID/password are valid, the MR 124 can verify that            the subscriber has rights to the requested service. If the            subscriber does have user rights to the service, the MR 124            can add the device address to the AuthorizedDevices table,            as well as to the MR 124 local cache and can assign a            security token to the client application running on the            client device 112.    -   6. The MR 124 can send an authenticated response message with a        success value to the client application to let the client        application know that the client application has been        authenticated; the security token can also be sent to the client        device 112; i.e., an indication of success;    -   7. The client application can re-send the original message        (step 1) that caused the authentication challenge with the new        security token; i.e., send request; and    -   8. The MR 124 can verify the device address against the        authentication cache of the MR 124 and can forward the message        to the proper BES 122 or HBES 132 (not shown).

FIG. 5 illustrates a flow diagram 500 depicting an exemplary embodimentof the present invention. Flow diagram 400 numerically depicts a flow ofmessages that can correspond to the authentication challengesuccess/failure. The diagram numerically shows message paths between theclient device 112 and the MR 124 including exemplary steps labeled bynumbers 1-7, as follows:

-   -   1. Client application can send an application message to the MR        124 (again, the PG 116 is not explicitly involved in        authentication, in an exemplary embodiment, all client/MR 124        communications can pass through the PG 116); i.e., device        authentication;    -   2. The client device 112 can fail the MRs 124 authentication;        -   There are several ways a device can fail authentication. For            example, the MR 124 cannot find the device address in its            local cache or the AuthorizedDevices table in the            intelligent messaging network MR database 128. The security            token of the client device 112 in the LinkStationID can be            not the same as the device's security token in the            intelligent messaging network MR database 128. The user of            the client device 112 can not have user rights to the            requested service.    -   3. The MR 124 can send a negative acknowledgment (NACK) message        to the client application with the appropriate error code;    -   4. The client application can respond with an authentication        request including the UserID, secure password and the requested        service type to authenticate; i.e., logon with userid and        password;    -   5. The MR 124 can check the UserID and password against the        AuthorizedUsers in the MR DB 128; the UserID, password can be        invalid and/or the user can not have rights to the requested        service;    -   6. The MR 124 can send an authentication response message with a        failure value to the client application to let it know that the        authentication has failed; i.e., authentication failure; and    -   7. The client may choose to prompt the client user 102, e.g., to        re-enter the UserID and password and repeat the flow diagram 500        starting from step 4; i.e., retry.

FIG. 6A illustrates a flow diagram numerically depicting a flow ofmessages that corresponds to a client application request to BES 122.The diagram numerically shows message paths between the client device112 and the MR 124 including exemplary steps labeled by numbers 1-6, asfollows:

-   -   1. The client application that can be running on client device        112 can create an application request (APP REQ) message and can        pass the message to the transport layer to transmit over the        network 212;    -   2. The transport layer can determine if the message needs to be        segmented into multiple segments; the transport layer can        transmit the message over the network and can wait for a        transport level ACK;    -   3. Upon receiving the APP REQ message, the PG 116 can assemble        the message segment into a complete application message (if        necessary) and can send the application message to the next        available MR 124;        -   If no MR 124 is available, a NACK message can be generated            by the PG 116 and can be sent back to the client application            with the appropriate error code. Preferably, the PG 116 can            not immediately send a transport ACK message back to the            client application. This can be done when the BES 122            receives the application message and sends an ACK control            message back to the PG 116.    -   4. The MR 124 can look up the device address and the service        type (first in its local cache, then if necessary in the        intelligent messaging network MR DB 128) to see if the message        is from an authorized source;        -   If the message is from an authorized source, the MR 124 can            choose the next available BES 122 that has been registered            to support the specified service type and can then send the            message to that BES 122. If there are no BESs 122 registered            that can support the specified service type, a NACK message            can be generated by the MR 124 and can be sent back to the            client application with the appropriate error code.    -   5. Upon receiving the application message from the MR 124, the        BES 122 can send an acknowledgement (ACK) control message back        to the PG 116 that received the application message; the BES 122        can also process the incoming message; and    -   6. Upon receiving the ACK control message from the BES 122, the        PG 116 can send a transport ACK message to the client        application at client device 112; in some exemplary embodiments,        sending ACK messages can be optional.

FIG. 6B depicts an exemplary embodiment of a message flow diagram 602illustrating transmission of a multi-segment message from a clientdevice 112 to a BES 122 according to the present invention. Flow diagram602 can begin with step 604.

In step 604, the simple network transport layer (SNTL) application cansegment the message into multiple segments, can encapsulate the segmentswith an SNTL segment header 1000, and can transmit the message initiallyto PG 116. An exemplary embodiment of a message header 1000 isillustrated below with reference to FIG. 10. As will be apparent tothose skilled in the relevant art, due to a high bit error rate inwireless communication links, it can be expected that not alltransmissions to PG 116 will be received from the client device 112.From step 604, the flow diagram can continue with step 606.

In step 606, the PG 116 can send to client device 112 an acknowledgement(ACK) of receipt of the transmitted messages at the PG 116. As shown, inthe exemplary embodiment, receipt of only segment 1 is acknowledged.Receipt of segment 2 is not acknowledged. From step 606, the flowdiagram 602 can continue with step 608.

In step 608, in an exemplary embodiment, client device 112 canautomatically retry, or retransmit segment 2 of the message to the PG116, since acknowledgement was not received for segment 2 in step 604.User datagram protocol (UDP) is an efficient communication protocol,however it is unreliable, lacking provision to segment messages andretransmit unacknowledged messages. In the exemplary embodiment, thepeer protocols of the SNTL layers on the client device 112 and PG 116can work in coordination with UDP to provide highly optimized andreliable wireless communication while using efficient connectionless(i.e., unlike TCP) UDP communication. In an exemplary embodiment, theSNTL layers can provide other useful transport functions such as, e.g.,pacing, congestion control and other functionality without requiring anentire TCP transport stack. The SNTL layer can include, in an exemplaryembodiment, a 4 bytes wide header. The header may be 6 bytes wide formulti-segment messages, as discussed with reference to FIG. 10. Fromstep 608, flow diagram 602 can continue with step 610.

In step 610, PG 116 can transmit the complete multi-segment message toMR 124. From step 610, flow diagram 602 can continue with step 612.

In step 612, MR 124 can route the message to BES 122 as discussed abovewith reference to FIG. 1C. From step 612, flow diagram 602 can continuewith step 614.

In step 614, BES 122 can send an acknowledgement of receipt of themulti-segment message to MR 124. From step 614, flow diagram 602 cancontinue with step 616.

In step 616, MR 124 can send acknowledgement of receipt of themulti-segment message at the BES 122 on to PG 116. From step 616, flowdiagram 602 can continue with step 618.

In step 618, PG 116 can send acknowledgement of receipt of themulti-segment message at the BES 122 on to client device 112. PG 116 canalso send acknowledgment of receipt of segment 2 of the message as well.In one exemplary embodiment acknowledgment of receipt of the secondsegment can occur following step 606. From step 618, flow diagram 602can immediately complete.

FIG. 7A illustrates a flow diagram 700 of an exemplary embodiment of thepresent invention. Flow diagram 700 numerically depicts a flow ofmessages that corresponds to a response from BES 122 to a request of theclient application, illustrated and described further above withreference to FIG. 6A. Flow diagram 700 numerically shows message pathsbeginning from the BES 122, through the MR 124 and PG 116 to clientdevice 112 including exemplary steps labeled by numbers 1-5, as follows:

-   -   1. A BES 122 can respond to a client application request as        illustrated in flow diagram 600; the BES 122 can pass the        response message (REQ RESP), message flags, customer ID and        LinkStationID (cached from the previous incoming request) in        flow diagram 700, which can represent a second or so-called        “send” call;        -   Message flags can specify whether to compress and/or encrypt            the message and whether the BES 122 requires an ACK message            when the PG 116 has successfully delivered the application            message to the client application running on client device            112. The BES 122 can send the application message to the            next available MR 124. If no MR 124 is available, then a            false can be returned from the send.    -   2. The MR 124 can use the LinkStationID to determine the        associated communication type (e.g., CDPD, Mobitex, etc.) and        can send the message to the next available PG 116 of the correct        communication type;    -   3. The PG 116 can segment the application message (if necessary)        and can transmit the application message over the network;    -   4. The transport layer can receive the message segment and can        assemble the message segment into a complete application message        (if necessary); the transport layer can send a transport ACK        message to the PG 116 that sent the message; it is important to        note that, in some exemplary embodiments, sending ACK messages        can be optional; and    -   5. When the PG 116 receives the transport ACK from the client        application, the PG 116 can send an ACK control message back to        the BES 122 (via the MR 124) that was the source of the original        message (if required).

FIG. 7B depicts an exemplary embodiment of a message flow diagram 702illustrating transmission of a multi-segment message from BES 122 to aclient device 112 according to the present invention. Flow diagram 702can alternatively represent sending of a multi-segment alert from BES122 to a client device 112. Flow diagram 702 can begin with step 704.

In step 704, BES 122 can transmit a multi-segment message intended for aclient device 112 to MR 124. From step 704, flow diagram 702 cancontinue with step 706.

In step 706, MR 124 can route the message to an appropriate PG 116 asdiscussed above with reference to FIG. 1C.

In step 708, the simple network transport layer (SNTL) applicationrunning on the PG 116 can segment the message into multiple segments,can encapsulate the segments with an SNTL segment header 1000, and cantransmit the segments of the message to the client device 112. Anexemplary embodiment of a message header 1000 is illustrated below withreference to FIG. 10. As will be apparent to those skilled in therelevant art, due to a high bit error rate in wireless communicationlinks, it can be expected that potentially not all transmissions from PG116 will be received at the client device 112. From step 708, the flowdiagram can continue with step 710.

In step 710, client device 112 can send to the PG 116 an acknowledgement(ACK) of receipt of the transmitted messages at the client device 112.Also, if the message is segmented, an acknowledgement of each segmentmay be returned. As shown, in the exemplary embodiment, receipt of onlysegment 1 is acknowledged. Receipt of segment 2 is not acknowledged.From step 710, the flow diagram 702 can continue with step 712.

In step 712, in an exemplary embodiment, PG 116 can automatically retry,or retransmit segment 2 of the message to the client device 112, sinceacknowledgement of receipt was not received for segment 2 in step 710.From step 712, flow diagram 702 can continue with step 714.

In step 714, client device 112 can transmit an acknowledgement thecomplete multi-segment message has been received to PG 116. This ispreferably done in connection with sending the acknowledgement of thelast message segment. From step 714, flow diagram 702 can continue withstep 716.

In step 716, PG 716 can send an acknowledgement of receipt of thecomplete multi-segment message to MR 124. From step 716, flow diagram702 can continue with step 718.

In step 718, MR 124 can send acknowledgement of receipt of themulti-segment message at the client 112 on to the BES 122. From step718, flow diagram 702 can immediately end.

The flow diagram 702 can be used in one exemplary embodiment to send aresponse from BES 122 to a request originating from client 112. Inanother exemplary embodiment, flow diagram 702 can be used to generatean unsolicited response, also commonly referred to as an “alert,” or a“push.” It is important to note that acknowledgement of receipt of aresponse message, as shown for example in flow diagram 702, is optional.For example, in the case of some client devices 112, such as, e.g., withsome paging devices, it may be impossible to send back from the clientdevices 112 an acknowledgment.

FIG. 8A illustrates a flow diagram 800 depicting an exemplary embodimentof the present invention. Flow diagram 800 numerically depicts a flow ofmessages that corresponds to an alert that can be sent from a BES 122 toa client application at client device 112. Flow diagram 800, in anexemplary embodiment, can proceed similarly to the method detailed inflow diagram 700 above describing sending a response message to arequest. A BES 122 unsolicited alert can be sent to a client applicationand can differ only slightly from the response from BES 122 to a clientapplication. The difference can include that the BES 122 is notresponding to a specific request and, therefore, does not know theLinkStation ID of the client application. However the BES 122 can knowthe customer ID or the customer ID and the port number of the clientapplication running on client device 112. Flow diagram 800 of FIG. 8Anumerically shows an exemplary alert message flow from the BES 122through MR 124 and PG 116 to the client application running on theclient device 112 including several exemplary steps labeled by numbers1-5, as follows:

-   1. a BES 122 can send an unsolicited alert to a client application;    the BES 122 can pass the alert message, message flags, null    LinkStation ID and customer/application information on the send    call;    -   The customer/application information can include the customer ID        or the customer ID and the port number of the client application        running on client device 112. Message flags can specify whether        to compress and/or encrypt the message and whether the BES 122        requires an ACK message when the PG 116 has successfully        delivered the message to the client application. The BES 122 can        then send the alert message to the next available MR 124. If no        MRs 124 are available, then a false can be returned from the        send call.-   2. The MR 124 can use the customer/application information to send    the alert message;    -   If the customer/application information includes only the        customer ID, then the MR 124 can search the local cache of the        MR 124 and, if necessary, can search the ActiveUsers table to        obtain the LinkStation ID associated with the customer ID. If        the customer/application includes both the customer ID and        application port number then the MR 124 can search the local        cache of the MR 124 and may also search the first device        assigned to the customer ID in the AuthorizedDevices table to        obtain the LinkStation ID. The MR 124 can use the LinkStation ID        to determine a communication type. (e.g., CDPD, Mobitex, etc.)        associated with the client device and can send the message to        the next available PG 116 of the correct communication type. If        the customer/application information includes only the customer        ID and the LinkStation ID and these are not found in the local        cache or ActiveUsers table, the MR 124 may not be able to send        the outgoing message to the client application with out further        information. In this case, the MR 124 can send a customer        inactive message back to the BES 122 that was the source of the        outgoing message. If the customer/application information is        both the customer ID and port number of the client application        running on client device 112, then the message can always be        sent if a device address is found in the AuthorizedDevices table        for the customer ID.-   3. The PG 116 can segment the alert into message segments (if    necessary) and can transmit the alert or message segments over the    network;-   4. The transport protocol layer can receive the alert or message    segments and can assemble the message segment into a complete alert    (if necessary); the transport protocol layer can send a transport    ACK message to the PG 116 that sent the message; it is important to    note that, in some exemplary embodiments, sending ACK messages can    be optional; and-   5. The PG 116 can receive the transport ACK from the client    application running on client device 112, and can send an ACK    control message back to the BES 122 that was the source of the    original message (if required).

In an alternative embodiment, the flow of FIG. 8A may differ from theflow described above. For example, the difference between a response andan alert may be that the response message to a request is given a clientinformation object when the BES 122 receives the request. This objectcan then be used to send the response as the client information objectpreferably has a LinkStation ID that is hidden in it. When a BES 122sends an alert, the BES 122 should be responsible for constructing theclient information object with the proper information, for example, acustomer ID and a device ID (the LinkStation ID that is hidden is null).The BES 122 needs to know only about the customer ID and device ID. Thedevice ID is an identifier associated with specific devices. The deviceID can be set to an ALL_DEVICES value. This value includes all devicesassociated with a particular customer. Thus, the port number of theclient application is not needed. By setting the customer ID and deviceID, the BES 122 can target a specific device. If the device ID is set toALL_DEVICES, then the message will be sent to all of the customer'sdevices.

Referring again to FIG. 8A, another exemplary alert message flow fromthe BES 122 through MR 124, and PG 116 to the client application runningon the client device 112 including several exemplary steps labeled bynumbers 1-5, will be described:

1. A BES can send an unsolicited alert to a client application; the BEScan pass the client information object, the alert message, the messagesend flags (for example, ACK_REQUIRED, SEND_IF_ACTIVE_ONLY,SEND_ONLY_ONCE), compression flag, and encryption flag on the send call.

-   -   The client information object can include the customer ID and        device ID. The device ID can be set to a defined value of        ALL_DEVICES if the BES 122 wants to send the alert to all        devices owned by the customer. Alternatively, the BES 122 can        specify a specific device ID if the BES 122 wants to target a        specific customer's device. Message flags can specify 1) whether        the BES 122 requires an ACK message when the PG 116 has        successfully delivered the message to the client application        (ACK_REQUIRED flag is set), 2) that the intelligent messaging        network only try sending the alert if the client is active on        the network (SEND_IF_ACTIVE_ONLY flag is set), 3) that the PG        116 should only try sending the message once and not perform        retries (SEND_ONLY_ONCE flag is set). The compression flags can        indicate if the message needs to be compressed or not and, if        so, what algorithm to use. The encryption flags can indicate if        the message needs to be encrypted or not and, if so, what        encryption algorithm to use.        2. The MR 124 can use the customer ID and device ID information        to send the alert message;    -   The LinkStation ID in the client information object is null so        the MR 124 should use the customer ID and device ID to construct        one or more LinkStation ID(s). The following are 4 possible        scenarios.    -   1) If the message send flag is set to SEND_IF_ACTIVE_ONLY and        device ID is specified, then the MR 124 may first looks in its        local cache to obtain the LinkStation ID of the specified        device. If the device is not found in its local cache, the        device could be active within the network on some other MR 124.        Therefore the MR 124 may look in an ActiveUsers table to obtain        the LinkStation ID of the customer's device.    -   2) If the message send flag is set to SEND_IF_ACTIVE_ONLY and        device ID is set to ALL_DEVICES, then the MR 124 should only        look in the ActiveUsers table to obtain the LinkStation ID's of        all the customer's devices active on the network.    -   3) If the message flag is not set to SEND_IF_ACTIVE_ONLY and the        device ID is specified, then the MR 124 may first look in its        local cache to obtain the LinkStation ID of the specified        device. If the device is not found in its local cache, then the        MR 124 should look in an AuthorizedDevices table to obtain the        LinkStation ID.    -   4) If the message flag is not set to SEND_IF_ACTIVE_ONLY and the        device ID is set to ALL_DEVICES, then all of the customer's        device(s) information is retrieved from the AuthorizedDevices        table.        -   Using the retrieved information, the MR 124 constructs the            LinkStation ID(s). If the device(s) are found, either from            the cache or the database, the MR 124 uses the Linkstation            ID of each device to determine the associated communication            type (e.g., CDPD, Mobitex) and can send the message for each            LinkStation ID(s) to the next available PG 116 of the            correct communication type. If no device(s) are found, the            MR 124 sends a customer inactive message if the send message            flag is set to SEND_IF_ACTIVE_ONLY. Otherwise the MR 124 can            send a customer not valid message back to the BES 122 that            was the source of the alert message.

If ALL_DEVICES is set for the device ID, then once the MR 124 has foundall the devices for a particular customer, the MR 124 can send back tothe BES 122 each of the device ID's found to correlate any ACK's. Thisis preferably done before the MR 124 sends the alert message to the PG116.

3. The PG 116 can segment the alert into message segments (if necessary)and can transmit the alert or message segments over the network;

4. The transport protocol layer can receive the alert or messagesegments and can assemble the message segment into a complete alert (ifnecessary). Once the transport assembles the message, it will send themessage to any application that have opened the transport and haveexpressed interest in the same type of message as the alert message.Once the message is delivered to the application the transport protocollayer can send a transport ACK message to the PG 116 that sent themessage; it is important to note that, in some exemplary embodiments,sending ACK messages can be optional; and5. The PG 116 can receive the transport ACK from the client applicationrunning on client device 112, and can send an ACK control message backto the BES 122 that was the source of the original message (ifrequired).

FIG. 8B depicts an exemplary embodiment of a flow diagram 802illustrating transmission of a hybrid alert from BES 122 to clientdevices 112 a, 112 b. Flow diagram 802 can begin with step 804.

In step 804, BES 122 can send a hybrid alert message to MR 124 for aclient user who can have multiple client devices 112 a, 112 b. Themultiple client devices 112 a, 112 b may operate using differentprotocols and/or different networks. Also, BES 122 can send a messagethat can be delivered to the same client device via alternate paths. Thealternate paths may include sending the message to the same clientdevice using a different protocol on a different network. In anexemplary embodiment, the hybrid alert can include XML query conditions.The query can query, e.g., the MR DB 128 or other database, to determinethe status of particular conditions. For example, the client user mayhave multiple devices as mentioned above. The client user's clientrecord can indicate that redundant alerts should be sent to all devicesat once. Alternatively, the client user's client record could indicate,e.g., that a message should be sent to a primary, or highest prioritydevice first, and if no acknowledgement of receipt of the message fromthe primary device is received, then the message can be sent to asecondary or lower priority device, and so on, in the event that theclient user has multiple client devices. Alternatively, the message canbe sent to the same client device over different protocols or networks.Thus, a single message generated by BES 122 can be delivered to multipleclient devices, sequentially or in parallel, or over multiple paths tothe same client device. The BES 122 need not be concerned with thedifferent protocols, networks, or devices that may be used. From step804, flow diagram 802 can continue with step 806 a or 806 b.

In an exemplary embodiment, the MR 124 can route the hybrid alertmessage to any of client devices 112 that match the query conditions. Inone exemplary embodiment, the user may have multiple client devices 112a, 112 b. Suppose the criterion are such that the hybrid alert is to besent to both client devices 112 a and 112 b. The hybrid alerts can besent in parallel or sequentially.

In step 806 a, MR 124 can route the hybrid message to PG 116 a. Fromstep 806 a, flow diagram 802 can continue with step 808 a.

In step 806 b, MR 124 can route the hybrid message to PG 116 b. Fromstep 806 b, flow diagram 802 can continue with step 808 b.

In step 808 a, PG 116 a can route the hybrid alert message to clientdevice 112 a. From step 808 a, flow diagram 802 can continue with step810 a.

In step 808 b, PG 116 b can route the hybrid alert message to clientdevice 112 b. From step 808 b, flow diagram 802 can continue with step810 b.

In step 810 a, in one embodiment, client device 112 a can send back toPG 116 a a message acknowledging receipt of the hybrid alert message.Acknowledgment of receipt of an alert can be optional. From step 810 a,flow diagram 802 can continue with step 812 a.

In step 810 b, in one embodiment, client device 112 b can send back toPG 116 b a message acknowledging receipt of the hybrid alert message.Acknowledgment of receipt of an alert can be optional. From step 810 b,flow diagram 802 can continue with step 812 b.

In step 812 a, in an exemplary embodiment, the PG 116 a can forward onthe acknowledgement of receipt at the client device 112 a to MR 124.From step 812 a, flow diagram 802 can continue with step 814 a.

In step 8126, in an exemplary embodiment, the PG 116 b can forward onthe acknowledgement of receipt at the client device 112 b to MR 124.From step 812 b, flow diagram 802 can continue with step 814 b.

In step 814 a, in an exemplary embodiment, MR 124 can forward theacknowledgment of receipt on to BES 122.

In step 814 b, in an exemplary embodiment, MR 124 can forward theacknowledgment of receipt on to BES 122.

FIG. 8C depicts an exemplary embodiment of a flow diagram 816illustrating a client device 112 a which becomes unavailable whentransmissions are being sent to it, which can prompt a hybrid alert tobe sent to another client device 112 b as shown, e.g., in flow diagram802 of FIG. 8B. The MR 124 may determine that an alternate path isavailable prior to forwarding the request to BES 122. Querying the MRdatabase 128 or another database as described above may do this. Theexistence of alternate paths can then be included in the messageforwarded by the MR 124. The existence of an alternate path is indicatedby the asterisks in FIG. 8C. When a message has an asterisk the messageknows if an alternate path is available. The message may then carry thisinformation around with it from then on. This is shown in steps 820 and830, for example, when the asterisk appears there after the messagepasses through the MR 124. In an exemplary embodiment, only the MR 124has access to the database to determine if an alternate path isavailable, thus the asterisks appear only as a message passes throughthe MR 124.

Flow diagram 816 can begin with step 818. In step 818, BES 122 canattempt to send an alert to MR 124 intended for client device 112 a.From step 818, flow diagram 816 can continue with step 820.

In step 820, MR 124 can route the alert to a PG 116 a associated withclient device 112 a. From step 820, flow diagram 816 can continue withstep 822.

In step 822, according to the exemplary embodiment, suppose clientdevice 112 a is unavailable to receive, and thus a negativeacknowledgement of receipt (NACK) can be sent to MR 124. In oneembodiment, the PG 116 a can be aware that an alternate path can beavailable, i.e., that another client device 112 b with which the BES 122can communicate. This may be done via communication with the MR 124.From step 822, flow diagram 816 can continue with step 824.

In step 824, the negative acknowledgement (NACK) of receipt at clientdevice 112 a can be forwarded on from the MR 124 to BES 122. BES 122 canbe notified in the NACK, in one embodiment, that the BES 122 can sendthe alert using a hybrid alert such as, e.g., that depicted in flowdiagram 802 of FIG. 8B, to reach the client user using client device 112b (not shown in FIG. 8C). Alternatively, the BES 122 need not generateanother message and the message router and protocol gateways canautomatically send the alert via an alternate path.

Flow diagram 816 also depicts a request from client device 112 a beingsent to BES 122 which can begin with step 826.

In step 826, the client device 112 a can send a request message to a PG116 a. From step 826, flow diagram 816 can continue with step 828.

In step 828, PG 116 a can forward the request on to MR 124. From step828, flow diagram 816 can continue with step 830.

In step 830, MR 124 can forward the request to BES 122. From step 830,flow diagram 816 can continue with step 832.

In step 832, BES 122 can send a response message intended for clientdevice 112 a to MR 124. From step 832, flow diagram 816 can continuewith step 834.

In step 834, MR 124 can route the response message to a PG 116 aassociated with intended recipient, client device 112 a. From step 834,flow diagram 816 can continue with step 836.

In step 836, suppose that the PG 116 a determines that client device 112a is unavailable to receive a message, so a negative acknowledgment ofreceipt of the response message at the client device 112 a can be sentto MR 124. From step 836, flow diagram 816 can continue with step 838.

In step 838, MR 124 can forward on the NACK message to BES 122 notifyingBES 122 that the response message was not received by client device 112a. In an exemplary embodiment, BES 122 can be notified that the clientuser can be reached using another client device 112 b. BES 122 can benotified in the NACK, that the BES 122 can send the response messageusing a hybrid alert such as, e.g., that depicted in flow diagram 802 ofFIG. 8B, to reach the client user using client device 112 b (not shownin FIG. 8C). Additionally, the MR 124 may determine client device 112 bis available or that client device 112 a can be reached via an alternatepath. The MR 124 may then automatically send the response to clientdevice 112 a or 112 b without further instruction from BES 122.

VII. Remote Monitoring of Servers

To assist in monitoring the intelligent messaging network, a system andmethod for publishing information from the servers can be provided. Inthis context, the term “servers” can include PG 116, MR 124, and BES122, as well as other servers. A list of available servers accessiblefor monitoring by persons, devices, and applications via a remotemonitor device can be provided. The remote monitor client may forwardselected servers from the list of available servers in which there isinterest. Also, particular information about the selected servers can berequested. Access to the servers and information may be restricted tothose with authorization. Authorization can be verified by the use ofdigital certificates, as described below. The requested information canthen be gathered and provided to authorized persons or devices.Typically, the information includes logging and status information fromthe servers. In a preferred embodiment, the information can be providedas an XML page and viewed using, for example, a standard web browser.Further, if the information is provided to the remote monitor device asan XML page, a standard XML parser may be used to extract particularinformation about the servers from the XML page. This feature enhancesthe ability of the remote monitor client to process information andperform analysis.

FIG. 9A depicts in a detailed block diagram an exemplary embodiment of asystem for remote monitoring. PGs 116, firewall 120, BESs 122, MRs 124,SNMP Consoles 134, content provider 140, and internet server 142 may beprovided and connected using WANs/LANs 118 as shown in FIG. 9A. Adetailed description of these components and their arrangement isprovided above with respect to FIG. 1A and will not be repeated here.Means 900 may be provided to interface with the servers and obtain theinformation from the servers. Means 900 can also provide an interfacewith the remote monitor clients 906. In this embodiment, means 900includes a number of web servers 902-1-902-n. Of course, other means forinterfacing with the servers can be used. Here, to access the servers,the web servers 902 can be connected to WANs/LANs 118. HTTP may be usedas the protocol to communicate between the web server 902 and the PGs116, BESs 122, and MRs 124. Remote monitor clients 906 a, 906 b can beused to pull the information about the servers from the web server 902for analysis and processing. Remote monitor clients 906 a, 906 b may bepersonal computers, workstations, and the like and can be connected toweb servers 902 through a network 904. Network 904 may be, for example,the Internet, a virtual private network, LAN, WAN, etc. HTTP-S ispreferably used as the protocol for communication between the remotemonitor clients 906 and the web servers 902.

Additionally, to verify authorization of remote monitor clients 906 toaccess the system, a X.500 and X.400 capable PKI (Public KeyInfrastructure) like Entrust or VeriSign may also be installed on eachof the web servers 902-1-902-n. The PKI is used to facilitate coredigital certificate storage, issuance, and management services, as wellas distribution of certificates and certificate-revocation lists toremote monitor clients 906 and other servers. The remote monitor clientshould have a digital certificate installed on it for the authorizationprocess. Digital certificate management may be privately managed orprovided by a third party certificate server. Other forms of certificateservers (e.g., web certificate servers and wireless certificate servers,which are available from VeriSign, Inc., Mountain View, Calif. U.S.A.)may likewise be deployed on each of the web servers 902.

In order to better illustrate the remote monitoring process, an exampleof the process will be discussed in connection with FIG. 9B. Thisprocess may be performed using computer programs running on the webserver 902, remote monitor client 906, and the servers. FIG. 9Billustrates communication exchanges between different components in thesystem during remote monitoring according to an embodiment of theinvention. Typically at the start of the process, a remote monitorclient 906 requests a list of servers available for monitoring,message 1. Message 1 is transmitted through network 904 to web servers902. The web servers 902 receive message 1 and begin to assemble thelist of servers. The list of available servers may have been stored in adatabase. The database may be MR database 128 that maintains a list ofavailable servers in the intelligent messaging network, as describedabove in connection with Section I., subsection E. The database isaccessed by the web server 902 to retrieve a list of available servers,message 2. The list of available servers that is eventually provided tothe remote monitor client 906 might include only those servers for whichthat remote monitor client 906 has authorization. An authorization oraccess level to the servers and to information from the servers may beestablished for the remote monitor clients 906. For authorizationpurposes, each remote monitor client 906 can be associated with anaccess level. Verification of access levels may be done using a digitalcertificate containing the necessary authorizations. Accordingly, usingthe PKI described above, the web servers 902 can control access by theremote monitor clients 906 to the servers and information.

After retrieving the list of available servers from the database, theweb server 902 can provide the list to remote monitor client 906,preferably as an XML page. From the list of available servers, theremote monitor client 906 can select those servers in which they have aninterest and provide those selections to web server 902. In addition toselecting servers, the remote monitor client 906 may select the type ofinformation it wants from that server. For example, a remote monitorclient may select to receive only information regarding inbound messagetraffic on a protocol gateway. The selections of servers and informationcan be in the form of HTTP get commands that are transmitted to the webserver 902, message 4.

Upon receipt of the remote monitor client's 906 selections in message 4,the web server 902 begins to dynamically generate a response includingthe requested information. Initially, to form the response, the webserver 902 may examine its cache for the necessary information. If thenecessary information is present in the cache, the web server 902 canthen generate and forward a response to the remote monitor client 906,as described below. However, in some situations, the necessaryinformation may not be present in the cache, for example, when a requestis made for information more recent than the information presently inthe cache. The web server 902 may then request the necessary informationfrom an appropriate server. This request may be an HTTP get commandissued from the web server 902 to the appropriate server, for example,PG 116, BES 122, or MR 124. The server receiving this request shouldprovide the required information in response, preferably as an XML page.Messages 5-7 represent communication of requests and responses betweenthe web server 902 and PGs 116, BESs 122, and MRs 124. The informationreceived from the servers in messages 5-7 is then stored in the webserver's 902 cache and is readily available to respond to other requestsfrom the remote monitor client 906. If for any reason a server is notavailable to respond to a request from the web server 902, anappropriate error message is generated.

After the necessary information is present at the web server 902, theweb server 902 can generate a response, message 8, to the remote monitorclient's 906 request, message 4. The response provides the requestedinformation, preferably as an XML page to the remote monitor client 906,message 8. One advantage of providing the information as an XML page isthat information in this form can be viewed using a web browserapplication present on the remote monitor client 906. The web browsermay display information from one or more servers simultaneously. Also,an XML parser can be used by the remote monitor client to extractspecific information from the XML page, for example, for logging andanalysis purposes.

Thus, through network 904, remote monitoring of the flow of messagesthrough PG 116, BES 122, or MR 124 or other servers can be accomplished.Logging and status information can be obtained at remote locations tomonitor and improve performance of the intelligent messaging network.

VIII. Software Development Kits

A. Mobile Client SDK

The Mobile client SDK is comprised of the following set of platformspecific libraries. Each of the following exemplary libraries exports aneasy to use API:

Utility Library;

Transport Library; and

Security Library.

An exemplary embodiment of the invention, includes a utility libraryproviding compression services. By keeping the transport libraryindependent from both the utility and security implementation details,new compression and security mechanisms can be added without theknowledge of the transport library. The independence eliminates the needto regression test the transport library, as well as all applicationusers of the transport library when adding a new compression or securitymechanism. Because the compression and security solutions may not meetthe need for all intelligent messaging network enabled applications,when new applications are developed, any specific compression orsecurity requirements of such applications may be accommodatedtransparent to the transport library individually, on a component basis.By providing wrapper APIs that encapsulate the default implementation ofthe utility and/or security libraries, developers could choose to writeto the wrapper APIs, or directly to the utility and/or security APIs.

I. Utility Library of the Intelligent Messaging Network

The utility library of the intelligent messaging network can provideapplications with functions to perform via an easy to use API. Thefollowing section summarizes the major functions provided by the utilitylibrary.

A. I/O Streaming

Provides functions to assist developers with handling applicationmessages that are streaming in and out (two ways). Serial in and outfunctions are provided for most of the common data types supported bythe target platform. The streaming functions manage the big-endianlittle-endian issues on behalf of the application.

B. Compression Mechanism

Applications can optionally compress/encode application messages priorto transmitting the message to a target destination. If the encodealgorithm determines that it is not optimal to encode the message, themessage should not be encoded. Also, applications can optionally decodeapplication messages prior to processing the message. In order todetermine if a message needs to be decoded, applications can check theencode flag contained in the message header.

C. AIM Message Header

Every application message should be pre-fixed with the intelligentmessaging network message header prior to being sent to its targetdestination. The intelligent messaging network utility library providesapplications with functions to set/get the contents of the intelligentmessaging network message header. It can also provide functions toserial out and serial in the contents of the intelligent messagingnetwork message header. Applications are not required to know theinternal data representation of the intelligent messaging networkmessage header.

D. AIM Authentication Messages

In order to access the intelligent messaging network via an ISP dialupconnection, the intelligent messaging network can require that the userprovide security credentials to identify themselves. The intelligentmessaging network utility library provides functions to build theintelligent messaging network authentication request message.Applications are not required to know the internal data representationof the intelligent messaging network authentication request message,likewise for the intelligent messaging network authentication responsemessage. Functions are provided to determine the authentication statusof the request.

2. Transport Library of the Intelligent Messaging Network

The transport library can provide reliable, optimized data communicationover various wireless networks, such as the CDPD and Mobitex wirelessnetworks, as well as ISP dialup wire line access to enabled theintelligent messaging network client applications via an easy to useAPI. The following section summarizes the major functions provided bythe mobile client transport library.

-   -   Designate Target Destination—The client application can specify        the target destination of the machine to receive the message.    -   Notification of Success/Failure of Transmission—The client        application receives notification of the success or failure of        the message transmission. For those platforms that support a        multi-threaded environment (e.g. WinCE), the notification        mechanism can be via an event that the transport library        asserts. For those platforms that do not support a        multi-threaded environment (e.g. Palm OS), the client        application may be required to continuously poll the transport        library to determine if the message transmission was successful        or failed.    -   Message Segmentation—All messages that are greater than the        maximum segment size (configurable) should be segmented into        multiple message segments.    -   Message Re-Assembly—All multi-segmented messages received are        re-assembled into a single message prior to presenting the        message to the client application running on client device 112.    -   Message Retries—All message segments that are not acknowledged        by the peer wireless protocol layer within the configured time        may be retried the configured number of attempts before        notifying the client application that the message was delivered        (acknowledgment) or not (negative acknowledgment).    -   Configurable Communication Parameters—The communication        parameters for the mobile client transport library can be        tailored to the required communication behavior. These values        can be configured via the registry (WinX platforms) or the        preferences database (Palm OS platforms) prior to opening the        mobile client transport library.    -   Duplicate Message Segment Detection—All duplicate message        segments received by the mobile client transport library can be        acknowledged back to the peer wireless protocol layer,        discarded, and conditionally logged.    -   Duplicate Message Detection—All duplicate messages received by        the mobile client transport library can be acknowledged back to        the peer wireless protocol layer, discarded, and conditionally        logged.

A layered architecture can be used for developing the transport library.Under this arrangement, each layer (excluding the bottom) can encompasscertain functions, can request services from the layer directly belowit, and each layer (excluding the top) can provide services to the layerdirectly above it. In order for a layer to do the job it is assigned toperform; layer N employs the services of layer N−1. The division of thenetwork into logical layers can allow a higher level to make use of themore primitive functions of lower levels, without having the layerconcern itself with the implementation details of those primitives.

A. Protocol Stack

FIG. 3 depicts an exemplary embodiment of a block diagram 300 of thepresent invention. Block diagram 300 illustrates a proprietary wirelessprotocol stack of the present invention including a mapping to thelayers of the OSI model as illustrated in the left column. Like theTCP/IP protocol stack, the protocol stack of the present inventionincludes only 5 layers. The highest layer is the applications layer,which corresponds to layer 7 in the OSI protocol stack reference model.Layer 4, the transport layer is the proprietary simple network transport(SNTL) layer of the present invention. Layer 3 is the network layer,corresponding to OSI layer 3. Layers one and two of the OSI model havebeen combined in the figure for ease of reference and include the datalink and physical layers for a variety of supported protocols forspecific classes of client devices. Because symmetry is assumed, each ofthe PGs 116 has a symmetrical protocol stack. Each client device 112 canhave only one of the combination layers corresponding to OSI layers oneand two. Similarly, while each of the PGs 116 could have one or more ofthe layers corresponding to the combination OSI layer one and two, anexemplary embodiment can include for each PG 116 having only onecombination layer corresponding to layer one and two.

i. Application Layer

The function of application layer (layer 7 of the OSI stack) is toprovide an interface between the application and the transport protocollayer by which client applications can send and receive messages acrossmultiple wireless networks (or via dial-up ISP access) without havingknowledge of the communication implementation.

In an exemplary embodiment of the present invention, layers 4 caninclude, e.g., applications such as, e.g, mail, file transfer, and otherapplications such as, e.g., end user applications.

ii. Transport Layer

This layer logically represents layer 4 of the reference model for thepresent invention. This layer provides the control structure formanaging the communications between two communicating peer transportlayers. The following sections detail the functions provided by thisprotocol layer.

The highest layer is the application layer. Layer 4 is the transportlayer and, in an exemplary embodiment, includes a connectionlessUDP-like transport protocol that has many of the features and advantagesof TCP. That is, the transport layer is connectionless like UDP but hasmany of the features of TCP including but not limited to messagesegmentation, message segment reassembly, message retries, and messageduplication but has only a four to six byte header.

In an exemplary embodiment of the present invention, layers 4 caninclude, e.g., the simple network transport layer (SNTL) protocol of thepresent invention.

iii Lower Layers

The network layer (layer 3) such as, e.g., the Internet Protocol (IP)layer is responsible for providing network protocol layer functionalityand hiding the details of this functionality from the transport layer.Below the network protocol layer is the data link protocol layer (layer2) and finally the physical protocol layer, which handles modulation andradio transmission.

In an exemplary embodiment of the present invention, layers 1 and 2 caninclude any of, e.g., the PSTN 308 a, CDPD 308 b, Mobitex 308 c, Ardis308 d, GPRS, and other, and future protocols 308 e, and GSM 308 f.

Message Segmentation

All messages to be sent over the network that exceed the maximum segmentsize (configurable) are segmented into multiple message segments. Thesegment size is configured prior to the client application opening thetransport library. The default maximum segment size is 512 bytes.

Segment Header

A transport header is prefixed to every outbound message segment. Thetransport header is encoded in network-byte order. It is the soleresponsibility of the application to encode any application specificdata in network-byte order prior to calling the AeTransportSendinterface function. The diagram below details the transport headerfields.

FIG. 10 illustrates a diagram 1000 illustrating an exemplary embodimentof the present invention. Diagram 1000 depicts an exemplary embodimentof an exemplary segment header and exemplary components 1002-1010 of theheader. In an example embodiment, a type I header can include a singlesegment message header, and a type II header can include a multiplesegment message header. It will be apparent to those skilled in therelevant art, that various other header formats can be used within thespirit and scope of the present invention.

-   -   VER 1002    -   This field contains the version number of the Segment Header. It        consists of two bits, bit 0 and bit 1 of the 1^(st) word in the        Segment Header. Valid values are 0 through 3.    -   MESSAGE ID 1004    -   This field contains a message identification value. It consists        of thirteen bits, bits 2 through 14 of the 1^(st) word in the        segment header. Valid values are 0 through 8,192. The transport        protocol layer uses the message ID to discard segment/message        duplications and to match acknowledgments with messages.    -   FLAGS 1006    -   This field contains protocol information. It consists of five        bits, bits 15 through 19. Valid values are:    -   Bit 19—segmentation indicator (0—message not segmented,        1—message segmented)    -   Bit 18—reserved    -   Bit 17—reserved    -   Bit 16—message type (0—positive acknowledgment, 1—negative        acknowledgment)    -   Bit 15—message indicator (0—application message, 1—AIM control        message)    -   TOTAL LENGTH 1008    -   This field contains the total number of bytes contained in the        message segment to be sent including the segment header. It        consists of twelve bits, bits 20 through 31 of the 2^(nd) word        in the segment header. Valid values are 4 through 4,096.    -   SEGMENT NUMBER 1010    -   This field identifies the number of this message segment. It        consists of 8 bits, bits 0 through 7 of the 3^(rd) word in the        segment header. Valid values are 2 through 255. The peer        wireless protocol layer uses this number to re-order the message        segments into a single complete message. In a preferred        embodiment, his field is present only if the segmentation        indicator is set in the flags field.

Notification of Success/Failure of Transmission

The transport protocol layer retains knowledge of all outstandingmessage segments pending acknowledgment (message segments that have notbeen acknowledged by the peer wireless protocol layer) via a pendingacknowledgment queue. The pending acknowledgment queue maintainsinformation pertaining to message segments that have been successfullytransmitted and are pending acknowledgment from the peer wirelessprotocol layer. If an acknowledgment (positive or negative) is receivedfor a message segment that is not pending acknowledgment, the ACK isdiscarded and conditionally logged.

When all message segments have been positively acknowledged by the peerwireless protocol layer, the application is notified (if requested) witha message type of AIM_ACK_MESSAGE and the message ID value associatedwith the sent message. If the number of transmission attempts for themessage segment has exceeded the configured number of retry attempts,the application is notified with a message type of AIM_NACK_MESSAGE, themessage ID value associated with the sent message, and the 2 byte errorcode containing the reason why the message was not delivered. In orderto re-send a message that has been negatively acknowledged, theapplication calls a AeTransportSend interface function.

Message Retries

All message segments not acknowledged by the peer wireless protocollayer within the configured time are automatically re-transmitted. Thetime to wait for an acknowledgment from the peer wireless protocol layeris configured prior to the client application opening the transportlibrary. The default time to wait for an acknowledgment from the peerwireless protocol layer can for example be 15 seconds.

The transport protocol layer retries the configured number of timesbefore notifying the application that the message could not be delivered(negative acknowledgment). The number of times to retry is configuredprior to the client application opening the transport library. Thedefault number of retry attempts is 3.

Message Re-Assembly

All incoming message segments received (including duplicate segments)are immediately acknowledged back to the peer wireless protocol layerand are queued pending receipt of all message segments via the inboundmessage queues. The incoming message queues manages a separate inboundmessage queue for each different LinkStationID of the sender.

When all message segments have been received for a message, the segmentsare assembled into a complete message. If the message ID of theassembled message has been already received (duplicate message), themessage is discarded and conditionally logged. This layer keeps track ofthe last n message IDs received for each unique LinkStationID. Thenumber of message IDs to contain in the message look back queue isconfigured prior to the client application calling AeTransportOpen toopen the transport library. The default number of message IDs tomaintain in the message look back queue may be set to 10, for example.

The exemplary message header 1000 of FIG. 10 includes segment numberfield 1010 which can be used to identify the segment number of amulti-segment message. For multiple segment messages, an additionalfield (not shown) can be used to identify the total number of segmentsin a message. In an exemplary embodiment, the total number of segmentsfield could be 2 bytes wide. Advantageously, according to an exemplaryembodiment of the present invention, the simple network transport layer(SNTL) can use the information in the total number of segments field todetermine which segments of the total number sent were received asacknowledged, or are required to be retransmitted. The reader isdirected to FIGS. 6B and 7B above illustrating transmitting amulti-segment message, and retrying where a segment is not acknowledged.

3. Security Library of the Intelligent Messaging Network

The security library can provide encryption and decryption services tothe intelligent messaging network enabled applications via an easy touse API. The following section summarizes the major functions providedby the security library.

-   -   Key Exchange—Public and private keys may be used periodically to        establish a common secret key that both the client application        running on a client device and server use when exchanging        messages. The reason for this is that the overhead of encrypting        using public/private keys is much higher than when using a        single secret key. The message flows to securely establish a        secret key between a client application running on a client        device and a server is the responsibility of the security        library.    -   Encryption—Mobile client application running on a client device        can optionally encrypt application messages prior to        transmitting the message to the target destination. Messages are        encrypted with the secret key negotiated between the client        application running on a client device and the server.        Encryption is preferably always performed after compression.    -   Decryption—Mobile client applications running on a client device        can optionally decrypt client application messages prior to        processing the message. To determine if a message needs to be        decrypted, client applications can check the encryption flag        contained in the message header. Messages are decrypted with the        secret key negotiated between the client applications running on        a client device and the server. Decryption is preferably always        performed before compression.

B. Server Software Development Kit (SDK)

The Intelligent messaging network provides a server SDK environment toassist engineers developing PGs 116 and BESs 122. The server SDK can becomprised of an easy to use C++ API and a set of Windows NT 4.0libraries. The SDK can be logically divided into the following twocategories of classes:

-   1. Server classes—These are the core classes that server application    developers use when creating new PGs 116 and BESs 122. These classes    may have no Graphical User Interface (GUI); thereby allowing    developers to provide their own custom interfaces.-   2. Server user interface classes—These classes provide a graphical    interface to the Server classes. Use of these classes is not    required when developing a new Server.    AIM Server Classes

The Server classes can be organized in the following simple classhierarchy:

AeServer Class

The AeServer class is the base class for all of the other Server classesand encapsulates those functions that are common to all Servers. Theseinclude:

Server Registration/Deregistration—Server subclassesregister/de-register from the intelligent messaging network MR database128 themselves, using methods defined in this class.

Server to Server Connectivity—The logic that determines how two Serverslocate and connect to one another is implemented in the AeServer class.The connection flow consists of both establishing a TCP/IP connection aswell as the mutual exchange of ServerConnect messages as a means ofverifying the identify of each server.Server to Server Communication (TCP/IP)—AeServer encapsulates the TCP/IPcommunication between all Servers. Servers can use the communicationfunctions provided by this class to connect, disconnect, send messages,and receive messages over a TCP/IP connection to other Servers. TheAIMSvrPacket can be used as the standard unit of communication betweenall Servers. The sequence of same fields that may comprise theAIMSvrPacket are as follows:

AIMSvrPacket Layout

-   -   Version (4 bits)—The version number of the AIMSvrPacket.    -   Header Length (4 bits)—The length of the AIMSvrPacket header in        bytes. The AIMSvrPacket header consists of the first 5 fields of        the AIMSvrPacket: version, header length, flags, total packet        length and source server ID. This length is used by the TCP        connection classes to read enough of the packet in order to        determine the total size of the remainder of the packet.    -   Flags (BYTE)—contains protocol information. It consists of eight        flag bits, valid values are:    -   Bit 1—acknowledgment indicator (1—ACK required, 0—ACK not        required)    -   Bit 2—message type indicator (1—server connect message)    -   Bits 3-8—reserved for future use.    -   Total Packet Length (unsigned long)—Contains the total number of        bytes in the AIMSvrPacket (including the packet header).    -   Source Server Database ID (unsigned long)—Contains Database ID        (a unique value assigned to a server when the server registers        itself in the intelligent messaging network MR database 128 of        the originator of the packet.    -   LinkStationID (variable length)—Contains the device address of        the source or destination of the message contained in the        packet. This field's size and content varies depending on the        communications type (CDPD, Mobitex, etc) of the device.    -   Message ID (unsigned short)—server packet message identifier.    -   Customer ID (unsigned long)—intelligent messaging network MR        database 128 ID of the customer who owns the device targeted by        the message in the server packet. Although preferably always        present, this field does not always contain a valid value and is        set to 0 when not valid. This field is not valid when the        AIMSvrPacket contains a network control message        (server-to-server messages independent of application messages)        or when passing a client message to/from a PG 116 and MR 124.        The primary purpose of the field is for MR 124 to BES 122        communications, to identify the message source on incoming        messages, and target a specific customer device on outgoing        messages.    -   Port Number (unsigned short)—customer device port number.        Although preferably always present in the packet, this field        only contains a valid (non-zero) value when a BES 122 sends an        unsolicited message to a device.    -   Intelligent Messaging Network Message Header (in an exemplary        embodiment can include 6 BYTES)—All application messages should        prefix the intelligent messaging network message header to the        beginning of the application message. The intelligent messaging        network message header may consist of the following fields:

-   1. Compression Bits (3-bits)—0=message is not compressed, 1=System    supplied compression type, 2=supplier supplied compression type,    3=application supplied compression type.

-   2. Security Bits (3-bits)—0=message is not encrypted, 1=System    supplied encryption, 2=Supplier supplied encryption, 3=application    supplied encryption.

-   3. Version (3-bits)—Message header version.

-   4. Reserved Bits (7-bits)—Reserved for future versions.

-   5. Service Type (12-bits)—Identifies which type of service    (MarketClip, FX) the message pertains to. This field is used by both    indirect and direct routing.

-   6. Message Type (12-bits)—Uniquely identifies the message within the    context of the specified service type.

-   7. Server ID (1-byte)—Identifies a specific BES 122 of the given    service type. The value of 0 is reserved to indicate that indirect    routing is desired. A non-zero value indicates that the message is    targeted at a specific BES 122.    -   Message Body (variable length)—Contains the body of the        application message.        AeFEServer Class (for the PGs)

The AeFEServer class subclasses AeServer and encapsulates thosefunctions that are common to all PGs 116. All PGs 116 should be derivedfrom the AeFEServer class. This class may perform the followingfunctions on behalf of all PGs 116:

-   -   Encapsulates the Transport Header—Only this class preferably        knows the implementation details of the transport header. The        transport header contains control information for communicating        between the intelligent messaging network enabled client        applications and PGs 116.    -   Asynchronous (non-blocking) Notification of Success/Failure of        Transmission—This class optionally notifies the original sender        of the message indication of the success or failure of the        message transmitted to the client application running on client        device 112.        -   Message Segmentation—All outbound server messages to be sent            to the client application that are greater than the maximum            segment size (configurable) can be segmented into multiple            message segments.        -   Message Re-Assembly—All multi-segmented messages received            from the client application can be re-assembled into a            single message prior to sending the message to a MR 124 to            route to a registered BES 122.        -   Message Retries—All message segments that are not            acknowledged by the client device peer wireless protocol            layer within the configured time can be retried the            configured number of attempts before notifying the original            sender that the message was delivered (acknowledgment) or            not (negative acknowledgment).        -   Message Pacing—For large multi-segmented messages, many            device modems cannot keep up if they are quickly flooded            with a series of segments. PGs 116 contain a configurable            setting that can be set to slow up the transmission of            messages larger than a specified number of segments.        -   Duplicate Message Segment Detection—All duplicate message            segments received from the client device are acknowledged            back to the client device peer wireless protocol layer,            discarded, and conditionally logged.        -   Duplicate Message Detection—All duplicate messages received            from the client device can be acknowledged back to the            client device peer wireless protocol layer, discarded, and            conditionally logged.        -   Configurable Communication Preferences—The communication            parameters for the PG 116 can be configured to tailor the            communication behavior. These values are configured prior to            the starting the PG 116.            AeBEServer Class            The AeBEServer class subclasses from AeServer and can            encapsulate those functions that are common to all BESs 122.            This class may performs the following functions on behalf of            all BESs 122:    -   Generate ACK Control Messages—When this class receives an        incoming from a PG 116 routed via MR 124, it can create an ACK        control message and send it back to the originating PG 116 via a        MR 124. When the PG 116 receives this ACK control message, it        sends a transport layer ACK message to the client application on        a client device that originated the message indicating that the        message was delivered to the BES 122.    -   Process ACK Control Messages—When this class receives an ACK        control message from a PG 116, indicating that the server        application message was delivered to the client device, it        notifies the derived BES 122.    -   Message Compression/Decompression—AeBEServer is responsible for        compressing any outgoing messages and decompressing incoming        messages. If an AIM provided compression type is involved,        compression/decompression is done transparently relative to any        subclasses of this type. Alternately, AeBEServer subclasses may        implement compression in their message serialization.    -   Message Encryption/Decryption—AeBEServer is responsible for        encrypting any outgoing messages and decrypting incoming        messages. If an AIM provided encryption type is involved,        encryption/decryption is done transparently relative to any        subclasses of this type. Alternately, AeBEServer subclasses may        implement their own encryption algorithms by implementing the        appropriate virtual methods that is invoked by AeBEServer at the        appropriate times.        Derived PGs 116

All the intelligent messaging network developed PGs 116 should bederived from the AeFEServer class. Derived PGs 116 may provide thefollowing functions:

-   -   Encapsulate the Communication Layer—Derived PGs 116 provide the        network specific interface to the communication layer used by        the PG 116. The parent class (AeFEServer) does not know the        implementation details of the underlying protocol layer used to        send and receive messages to and from client applications        running on client devices 112. This is the sole responsibility        of the derived PG 116.        Derived BESs 122        All BESs 122, developed by the intelligent messaging network can        be derived from either the AeBEServer. Derived BESs 122 may        provide the following functions:    -   Process application Specific Messages—All application specific        knowledge is implemented in the derived BES 122. For example, a        news service can provide client devices with news stories        related to a specific financial entity. The derived new        services' parent class hierarchy (AeBEServer and AeServer) does        not know the implementation details of the application message        protocol. This is the sole responsibility of the derived BES        122.    -   Special Compression Services—If a BES 122 has specific        compression requirements for their application data that is not        addressed by the Intelligent messaging network supplied        compression, the BES 122 is responsible for providing the        compression mechanism.    -   Special Security Services—If a BES 122 has specific encryption        requirements for their application data that is not addressed by        the Intelligent messaging network supplied encryption, the        derived BES 122 is responsible for providing the encryption        mechanism.        Server User Interface Classes

The server user interface class hierarchy parallels the server classhierarchy and provides the following types of functionality:

-   1. Persistent storage of configurable server settings as well as a    common user interface for viewing/editing those settings.-   2. Screen based error logging.-   3. NT Event Log error logging and automatic batch file error    notification.-   4. Inbound/outbound message logging.-   5. Inbound/outbound message statistics.    AeServerApp

AeServerApp is the base class for all of the other server GUI apps. Allserver applications are complete, windows-based, executable programs.AeServerApp expects its subclasses to provide it with an instance of anAeServer subclass. Of the five areas of functionality listed above,AeServerApp may provide the following:

-   1. Persistent storage of configurable server settings and common    user interface framework for viewing/editing those settings.    —Persistent storage is implemented through the Windows registry and    AeServerApp provides the base registry key for all of its subclasses    to use. AeServerApp also provides a standard method of    viewing/editing server settings in the form of a PropertySheet.    Subclasses provide for their own individual server settings by    adding PropertyPages to the base class PropertySheet. AeServerApp    provides a common page for handling server settings common to all    server types.-   2. Screen based error logging. —In addition to providing a window    where system events and errors can be displayed, AeServerApp also    supplies a separate logging thread that can be used by subclasses    when displaying output to their own windows. This thread runs at    lower priority then the server processing threads so that screen    logging does not negatively impact performance.-   3. NT Event Log error logging and automatic batch file error    notification. —AeServerApp provides a mechanism whereby system    errors can be written to the NT Event log. The level of error    reporting is configurable. In addition to the NT Event log, users    may specify that a batch file be executed when an error of a    specified severity occurs. Such batch files could be used to    communicate problems to a system administrator via email or a pager.    AeFEServerApp

AeFEServerApp is derived from AeServerApp and may provides the followingadditional user interface features:

-   1. PG specific server settings—Preferably provides a user interface    and persistent storage for transport settings such as maximum number    of retries, retry timeout interval, segment size, etc.-   2. Inbound/Outbound message logging—Provides two windows that log    each inbound and outbound message. Makes use of the AeServerApp    logging thread. Logging may be enabled/disabled for either window.-   3. PG specific statistics—Gathers and displays statistical totals    such as number of messages sent/received, number of ACKS/NACKS    sent/received.    AeBEServerApp and CBEServerSampleApp

These classes provide a standard GUI for BESs 122. Both are derived fromAeServerApp and should both provide the same set of user interfacefeatures. The difference between the two classes is thatCBEServerSampleApp also derives from AeBEServer, while AeBEServerApp hasa AeBEServer member (inheritance vs aggregation). Other than that thetwo classes provide the same set of features:

-   1. Inbound/Outbound message logging—Preferably provides two windows    that log each inbound and outbound message. Makes use of the    AeServerApp logging thread. Logging may be enabled/disabled for    either window.-   2. Back-End specific statistics—Gathers and displays statistical    totals such as number of messages sent/received, number of    ACKS/NACKS sent/received, and compressed vs. uncompressed byte    totals.-   3. Application message log view—Provides an additional logging    window that applications should use to log their own errors or trace    statements rather than intermingling them with the system messages    in the system log window.

C. Wizards and Resource Kit of the Intelligent Messaging Network

In a well-known manner, intelligent messaging network can also providetools that work in conjunction with the Microsoft Visual DeveloperStudio framework. These tools assist engineers developing client and BES122 applications, as well as stress test and monitor the health of theintelligent messaging network.

1. Message Builder Wizard

The Intelligent messaging network Message Wizard makes it easy fordevelopers to define their application specific data content of theintelligent messaging network messages. The wizard makes it easier forthe developer to focus on adding business value to their applicationinstead of having to worry about the tedious and error prone task ofwriting the serialization code to transfer message content betweenserver and client. It also can automatically generate the code needed toserialize the message content between a client application and a BES 122application.

2. Back End Server App Wizard

The BES 122 App Wizard can make it easy for developers to create BES 122applications. The BES 122 App Wizard can generate the Visual Studio C++project and its associated program and header files to create a BES 122executable. BES 122 developers would then need to add program logic tosupport their application protocol.

3. Ping App Wizard

In order to assist engineers developing a BES 122 Ping application, theintelligent messaging network Ping App Wizard makes it easy fordevelopers to create a Ping BES 122 executable. The Ping App Wizard cangenerate the Visual Studio C++ project and its associated program andheader files to send an application defined “heart beat” message to aBES 122. BES 122 developers may want to use this tool as a way tomonitor the health of their BES 122.

IX. NT Client Simulation Application

In order to assist engineers developing BES 122s, the intelligentmessaging network can also provide a client simulation application.Developers can use the client simulation application to simulatemultiple clients and to generate BES 122 specific message traffic. Theclient simulation application supports the following major functions:

Simulate up to 256 clients

Support multiple communication networks

-   -   CDPD    -   Mobitex    -   Dial-Up    -   TCP/IP LAN

Configurable simulation attributes

-   -   Number of messages to send    -   Application defined messages    -   Relative send frequencies for each message type    -   Compression

Capture/present performance statistics

-   -   Total messages sent    -   Average message response time

From the forgoing description it may be appreciated that the presentinvention provides protection against technology obsolescence bysupporting seamless integration of information sources with multiplewireless networks and client devices. As such, the invention provides areliable method of data transfer, while optimizing bandwidth constraintof wireless data services and providing end-to-end security. Thisinvention allows for system growth by incorporating the new devices andwireless network technologies as they become available, without the needto modify client and server applications.

The above-described environment, which has a messaging basearchitecture, serves as the framework for implementation of theinvention. This environment can provide client/server connectivity,which can provide an enabling mechanism for application networkconnection connectivity. The architecture can support messaging.Platform transparency can be provided enabling platform independence ofclient devices. Network transparency can be provided by an enablingmechanism for network independence by hiding the underlining networkprotocol. The SDK can provide an easy to use developers tool kit andenvironment for the design development of each aspect of theapplication, the client device, and server.

Accordingly, the SKDs can provide a standard communication interface toallow clients and servers to interact with multiple wireless networks ina unified manner. This allows application developers to concentrate onbusiness logic, not writing wireless communication software.

While various exemplary embodiments of the present invention have beendescribed above, it should be understood that they have been presentedby way of example only, and not limitation. Thus, the breadth and scopeof the present invention should not be limited by any of theabove-described exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents.

What is claimed is:
 1. A method of retrieving information associatedwith web page content by a wireless client device, comprising:authorizing, via a digital certificate, access of a wireless clientdevice to a web page content server; sending, from a web browserassociated with said wireless client device, a request for web pagecontent to said web page content server, said web page content includingmessage flow information associated with at least one of a plurality ofmonitored servers; and receiving, via a physical receiver associatedwith said wireless client device, said web page content; wherein saidweb page content is parsable to extract particular information about aparticular server from said plurality of monitored servers.
 2. Themethod of retrieving information associated with web page content by awireless client device according to claim 1, wherein: said web pagecontent is received, via a physical receiver associated with saidwireless client device, according to an access level associated withsaid digital certificate.
 3. The method of retrieving informationassociated with web page content by a wireless client device accordingto claim 1, wherein: said request for web page content is transmittedvia a Transport Control Protocol/Internet Protocol (TCP/IP) protocol. 4.The method of retrieving information associated with web page content bya wireless client device according to claim 1, further comprising:receiving, via said physical receiver, said web page content in acompressed form.
 5. The method of retrieving information associated withweb page content by a wireless client device according to claim 1,further comprising: intercepting said request via a proxy InternetProtocol (IP)/port.
 6. The method of retrieving information associatedwith web page content by a wireless client device according to claim 1,further comprising: unpacking, via a wireless client device side proxy,said web page content into an HyperText Transfer Protocol (HTTP)response; and sending said HTTP response to said web browser.
 7. Themethod of retrieving information associated with web page content by awireless client device according to claim 1, further comprising:accessing a mobile library optimized for an underlying wireless protocolused by said wireless client device.
 8. The method of retrievinginformation associated with web page content by a wireless client deviceaccording to claim 6, wherein: said wireless client device side proxysits atop a mobile library.
 9. The method of retrieving informationassociated with web page content by a wireless client device accordingto claim 1, further comprising: compressing a raw payload of saidrequest for said web page content prior to transmission of said request.10. A wireless client device to retrieve information associated with webpage content, comprising: a web browser that receives an authorizingdigital certificate to permit access of a wireless client device to aweb page content server, and that sends a request for web page contentto said web page content server, said web page content including messageflow information associated with at least one of a plurality ofmonitored servers; and a physical receiver associated with said webbrowser to receive said web page content; wherein said web page contentis parsable to extract particular information about a particular serverfrom said plurality of monitored servers.
 11. The wireless client deviceto retrieve information associated with web page content according toclaim 10, wherein: said web page content is received, via a physicalreceiver associated with said wireless client device, according to anaccess level associated with said digital certificate.
 12. The wirelessclient device to retrieve information associated with web page contentaccording to claim 10, wherein: said request is sent via a TransportControl Protocol/Internet Protocol (TCP/IP) protocol.
 13. The wirelessclient device to retrieve information associated with web page contentaccording to claim 10, wherein: said physical receiver receives said webpage content in a compressed form.
 14. The wireless client device toretrieve information associated with web page content according to claim10, further comprising: a wireless client device side proxy to interceptsaid request for said web page content via a proxy Internet Protocol(IP)/port.
 15. The wireless client device to retrieve informationassociated with web page content according to claim 14, wherein: saidwireless client device side proxy unpacks retrieved informationassociated with said web page content into an HyperText TransferProtocol (HTTP) response, and sends said HTTP response to said wirelessweb browser client device.
 16. The wireless client device to retrieveinformation associated with web page content according to claim 10,further comprising: a mobile library optimized for an underlyingwireless protocol used by said wireless web browser client device. 17.The wireless client device to retrieve information associated with webpage content according to claim 14, wherein: said wireless client deviceside proxy sits atop a mobile library.
 18. The wireless client device toretrieve information associated with web page content according to claim14, wherein: said wireless client device side proxy compresses a rawpayload of said request for said web page content prior to transmittingsaid network message.